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