🚀 go-pugleaf

In article <5429@bacon.IMSI.COM>, jordan@IMSI.COM (Jordan Hayes) writes:
>Since when is UDP "more efficient" at full system load?  In the past
>few years, TCP has become a much more efficient protocol that it was,
>perhaps to the point where picking UDP over TCP "for performance
>reasons" may be a thing of the past.  Consider there are two cases: the
>first, where the number of messages is low and the network is lightly
>loaded, the extra effort to do TCP is not noticed.  The second, where
>the network is congested, allows you to take advantage of sophisticated
>congestion avoidance in more modern TCP implementations.  When the
>network is congested and the transport is UDP, the application
>programmer (whom I pity :-) must make up for this on her own.

I'm not sure I'm clear on what "UDP-based" and "TCP-based" means, or what
baggage you intend them to carry.  For example, while one can say (and
I'll admit to being lazy and saying myself) that, say, DCE RPC 
"runs over TCP and UDP", a more precise statement is that DCE RPC
*runs a protocol* over TCP and a protocol over UDP.  The former protocol
is pretty simple (although maybe not nearly as simple as one might
think).  The latter protocol is substantially more complicated since it
really IS doing much of the same work as the TCP protocol does, thus
the oft-heard "you're just duplicating TCP" plaint (with the implied
or stated "...and maybe you don't exactly understand how to do that"
and/or "...and how do you expect to duplicate the person-centuries of
work on TCP?").  Now I'm not saying these aren't valid concerns--they are.
It's just that it's not like people have been holding as trade secrets
the knowledge gained about TCP.  Thus, I can apply that experience to
my RPC protocol that runs over UDP.  (Note that this protocol could run
right on top of IP and perhaps do so to some advantage.  Unfortunately,
it would make it harder to make a portable implementation.)

The reason to invent an RPC protocol to run over UDP is to gain some
advantages from doing so.  For example, a "fully loaded cold call"--i.e.,
the first authenticated call to a server you haven't talked to in a while
and that's not using an assigned (i.e., well-known) port number--induces
a fair number more message round trips when using the RPC protocol over
TCP than when using the RPC protocol over UDP.  The number of round trips
isn't the absolute most important thing in the world, but it is a factor
to consider (esp. in long round trip times regimes).

>	I realize UDP may lose a few packets now and again, but the RPC
>	runtime will handle this for me.
>
>Yes, usually by retransmitting the *entire packet*.  Since the RPC
>runtime doesn't have access to "what part of the message got dropped"
>it has no choice but to resend everything.  In effect, you are asking
>to re-implement (poorly) everything that TCP does for you.

Aw, come on.  That happens only if someone is silly enough to be making
heavy use of IP fragmentation.  No one would do THAT, right?

And I'll echo John Dilley's comment--good conversation!
-- 
                    -- Nat Mishkin
                       Distributed Computing Program
                       Hewlett-Packard Company
                       mishkin@apollo.hp.com