ok, so im currently working on a P2P application, and NATs are getting on my way. I don't feel like using "punch through" because (please correct me if im wrong): * messages between two peers are no more than 2 or 3 (hi, hi, how are you?, fine, and thats about it), so spending more messages just to try to contact the other peer seems like a waste. * another very important reason is that this is sort of a massive broadcasting system (small messages to a lot of peers), so they won't be specting my messages (this means going to the server and ask for my address is not an option). So i was thinking that when a user logs in to the server , if he is behind a router the server will asign him a "bridge" (a peer with a public IP address). He will receive the bridge's address, and will start a TCP connection with him. So if anyone wants to talk to this peer, messages should be sent to his "bridge" instead of him, and the "bridge" will redirect the messages through the existing TCP connection. My question is, does this sound like a system that could work with thousands of users around the world? Considering the % of connections from a public IP and the % of connections behind a router, will my "bridges" be overloaded handling an impossible number of connections? Any comments and suggestions are welcome, thanks.

Keeping a TCP connection open per client that "might" want to communicate seems wasteful. Why couldn't you use UDP with the bridge? TCP is not optimized for small transactional exchanges, so you could probably do something at least as good on top of UDP, with the "bridge" inbetween. This will reduce the likelihood of the bridge becoming overloaded.

I wouldn't count on any large percentage of "home" or "coroporate" internet connections to be using public IP addresses. There will be some, sure, but my impression is that the large majority uses NAT these days.

Quote:Well, presumably if you can't connect to that client from the outside with TCP, you won't be able to with UDP either.

There's a significant amount of resources consumed by an open TCP connection. Thus, the number of TCP connections you can keep open at a time will be limited, especially if this is in the background on someone else's machine.

With the requirements as posted by the original requester, it would probably be more feasible to use UDP, because then the gateway machine would just need to respond to requests from a single socket, when and if they come in.

Quote:Why couldn't you use UDP with the bridge?

i thought i could not use UDP (sending AND receiving) through a router... can i? (if the peer behind the router sends the first packet?)

If the peer behind the router sends the first message, you can use UDP. However, you probably need to keep the connection open by sending a message every 9 minutes or so (depending on the timeout limit for the router's connection table -- stricter than 10 minutes is not too common). That might be useful to do as a keep-alive anyway, making the server know you're still paying attention.

thank you very much, i think ill go with udp.