On Mon, Jan 12, 2004 at 02:57:45PM -0500, Nathaniel Borenstein wrote: > Pardon me if I'm missing something obvious here, but couldn't one just > use either XMPP or Simple for presence, associate your "server name" > with a Jabber/Simple ID, and automatically have your "server" findable > via these general presence protocols? Why isn't that a reasonable > approach to peer to peer in a NAT world? I would contend that it's > even better in a mobile world -- your laptop might change IP address a > dozen times per day, but if it keeps reconnecting with your presence > server you could base a stable "host" identity on the IM ID to enable > peer to peer applications, couldn't you? XMPP or Simple solve the problem of dynamic IP addresses. NAT's however go beyond dynamic IP addresses, as they multiplex multiple hosts behind a single IP address. Many of these systems do not have an easy way to allow users to accept an incoming TCP connection (and unexpected UDP packets are often harder) to be happed to a particular host behind a NAT box. Doing so often requires administrative access to the NAT, and if you're lucky there is a manual web interface you can use to configure such access. If you're not so lucky there is a text config file you have to edit. In either case, this makes peer to peer much more difficult for the average user behind a NAT. Some might say that it is impossible. One could imagine developing a protocols for discovering NAT boxes, and making requests that they listen on certain ports and when they receive an incoming TCP connection, that it be remapped to a particular address behind the NAT box. This is not too bad for one NAT box, but if you start having multiple NAT boxes between the communicating partners, it starts becoming bad in a hurry. Of course, this isn't necessary so as long as one of the parties is not behind a NAT, but the moment both the sides are behind one or more levels of NAT, trying to do a peer-to-peer TCP connection between the two entities is non-trivial. - Ted