[OT] Handling multiple UDP clients through NAT

Levi Pearson levi at cold.org
Sun Feb 4 15:54:21 MST 2007


"Bryan Sant" <bryan.sant at gmail.com> writes:

> What Steve wants to do can be done with UDP.  It's the layer 3 part of
> the TCP/IP stack that handles source/destination address:port
> information.  UDP is built on IP (and TCP is built on UDP), so Steve
> can keep a unique list of users based on a source ip:port hash.  So it
> is possible.

Technically, UDP and TCP are both built directly on the IP layer; TCP
is not on top of UDP, they're side-by-side.  But since the IP layer
has the address and both UDP and TCP headers start with the
source/destination port, the distinction in this case makes little
difference.

My initial answer glossed over the NAT issue, since I think UDP (and
polling, and a thread-per-user architecture) is a bad design decision.
When someone asks a question like, "What's the best way to retrieve my
toast from the toaster with a metal fork?" I feel that suggesting a
plastic utensil instead is more prudent than answering the actual
question.

> Game makers will often use UDP for LAN games because:
> A) LANs are reliable
> B) Even if there is packet loss, newer packets always have updated
> information (such as x,y,z location, etc), so there is no need for an
> aggressive, re-transmitting protocol like TCP.

The graphical nature of these games, where the client is responsible
for creating the visual representation of the world, lends itself to
UDP as well.  MUDs are generally transmitting prose (or at least data
formatted for human consumption) and are as such far less tolerant of
losing data.

>
> TCP prevents packet loss and is generally "A Good Thing" (tm) when
> sending data across the (unreliable) Internet -- hence HTTP being TCP
> based even though it is a stateless protocol.
>

TCP is also designed to scale.  It has built-in congestion-control
features that keep things moving steadily (if more slowly) in extreme
traffic conditions.  UDP will just fall flat, since it has no concept
of traffic conditions and will happily let you keep sending packets at
far too high of a rate to sustain on a loaded pipe.

                --Levi




More information about the PLUG mailing list