Hello. Sadly, my internet provider doesn't offer active IP adresses. All the users (over 10000) use the same IP outside. This is done using NAT firewall. What I want is to open a TCP connection between two computers behind NAT. I read some articles about NAT-punching-through, but I presume this technique applies only to UDP. I need TCP. First question is - are there any free servers that I could use to make the punch-through? One of my friends has an active IP and he already agreed to run the service I supply for me (just for testing purposes), but he's not online 24/7. What I need is some server I send a name (or password or anything) from computers A and B, both behind NAT, and it then returns each another's IP and ports (of course the server must include it's protocol documentation...) I want to simulate TCP like this: when connecting via TCP from computer A to computer B, computer A contacts my application listening at localhost of A. This application is already connected with computer B using UDP and it transfers the TCP stream using UDP. The very same application at computer B recieves it, contacts target port and hands over the data. So basically I need to implement TCP using UDP. Second question - are there any tutorials on this? I tried to google, but the results did't satisfy me. I know I have to do some packet counting and acking, but I'm not sure how to implement it technically, eg. how long should I wait for the acknowledgement, how long should I wait for some missing packet before I request it again, and so on. Detailed technical documentation on how TCP works would be great. Thanks! Edit: I noticed there's an interesting thread on guaranteed UDP. So I will change the question a bit: what are the other features of TCP aside from guaranteed sequencial delivery (stream) that I would need to implement when creating a program like I described? [Edited by - Xerxes on October 23, 2004 6:48:11 AM]

TCP punch-through largely doesn't exist. You can, perhaps, use "simultaneous open" combined with guessing the next TCP connection port your NAT will use, but this is so problematic that you might as well not spend the effort -- it will only work in a small number of cases.

If you have an "echo" server that receives data and then forwards to someone else, that's not a "punch-through" or "introducer" server, because it has to copy all the data that flows on the connection. Running such a server would run up a large network bandwidth bill, and thus wouldn't make sense for a P2P application -- in essence, it wouldn't be peer-to-peer anymore.

If your ISP does not provide the kind of network connectivity you require, then you should probably first talk to them about changing your service, and if they can't do it, then choose another ISP.

No, you misunderstood the model of my application. I will try to explain it in more depth.

There are only two computers, each behind a NAT. They are running an application that connects them using UDP and some third-party match-maker (or introducer, I don't know the difference :)).

Now I want to connect them using TCP (the program already exist and cannot be rewritten to use UDP). I do it like this. The TCP program at computer A connects to my special application at the localhost of computer A. This application (already connected with computer B using UDP an NAT-punch-through) notifies computer B and an instance of my application at Computer B contacts the listening port of the TCP application running at Computer B at it's localhost. Then, my application handles the data transfer.

I drew a diagram:



So there's no "echo" server.

My major questions stay the same, thanks for the reply though!

I know of no free introducer/match-maker service. I'd be surprised if such a general-purpose service existed, as it's likely to be an administrative nightmare, and it would be very hard to make any money off of it. There are commercial matchmaking hosting solutions such as GameSpy available; that's the closest I can think of.

As far as features of TCP, I would suggest implementing congestion avoidance, sliding windows, collapse on re-transmit, and ack time-outs based on measured average RTT (times some multiplier, such as 2). A good description of a modern TCP implementation is found in the TCP implementation section of the Stevens networking book, if you want the details of how it's already been done.

You might want to add encryption, just for kicks :-) My favourite light-weight encryption algorithm is XTEA, but you have your pick of a large number of algorithms with various security, cost, and implementation implications.