[OT] Handling multiple UDP clients through NAT
bryan.sant at gmail.com
Wed Feb 7 13:33:34 MST 2007
On 2/7/07, Andrew McNabb <amcnabb at mcnabbs.org> wrote:
> When I took CS 460 (Computer Networking) at BYU, I loved the textbook we
> used. One of the main things I noticed was that they basically ignored
> the OSI model and instead focused on the Internet model (hardware
> layers; Ethernet and other link layers; IP, TCP/UDP). They were able to
> talk about the same issues but it was a little more relevant.
The two layers I spoke of exist in both models. It's applicable either way.
> I almost agree. UDP indeed deals with datagrams, but TCP does not. TCP
> deals entirely with streams (with all of the features you mentioned).
No, TCP abstracts datagrams so you *think* you're dealing entirely
with streams. Under the covers, TCP is transmitting segmented
messages with a datagram-ish payload. The receiving stack reorders
things, asks for re-transmits, etc, and finally servers data up to
your application code as if it were coming from an ordinary character
> There are things you can do with UDP that you can't do with TCP, so I'm
> still having a little trouble with the statement that the TCP feature
But there is nothing you can do with TCP that couldn't be done with
UDP (with a lot of work). UDP is a relatively raw, feature-less base
that TCP could be built on.
> set is a superset of the UDP feature set. For example, you can't send a
> message in TCP and expect it to arrive in one piece, and you can't look
> at your TCP data as a bunch of records (if you need records, you need to
> parse your stream).
>From the client code perspective you're right, but the TCP code is
indeed working with "a bunch of records". That's exactly what it's
And you don't have to parse records out of TCP. You could just expect
a fixed (zero padded?) record size... Or you could parse for a record
terminator. The point is that you can indeed use TCP like UDP save
certain things like broadcast etc, that TCP isn't designed for.
> However, one important point along the lines of what you were saying is:
> TCP can be conveniently implemented on top of UDP. You could also say
> that UDP is nothing but IP with port numbers.
That's the point I was trying to make. UDP is (or could be) a base
that the extended TCP features could be built on. Maybe super-set
isn't the right word to describe that relationship.
Futhermore, I would like to note that Datagram would be a cool name
for a rock band.
More information about the PLUG