Path: utzoo!attcan!uunet!zephyr.ens.tek.com!uw-beaver!mit-eddie!mintaka!olivea!samsung!zaphod.mps.ohio-state.edu!sdd.hp.com!apollo!apollo.hp.com!mishkin
From: mishkin@apollo.HP.COM (Nathaniel Mishkin)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Reliable Datagram ??? Protocols
Message-ID: <1990Oct24.090841@apollo.HP.COM>
Date: 24 Oct 90 13:08:00 GMT
References: <9010221418.AA03839@ftp.com>
Sender: root@apollo.HP.COM
Reply-To: mishkin@apollo.HP.COM (Nathaniel Mishkin)
Organization: Hewlett-Packard Company - Cooperative Object Computing Operation
Lines: 37

In article <9010221418.AA03839@ftp.com>, jbvb@FTP.COM (James B. Van Bokkelen) writes:
>So, every time this came up in the past, the next stage was to ask the
>person looking for a "reliable connectionless protocol" or somesuch what
>was really needed.  The most frequent goal has been some sort of transport
>for a little machine, or a new one for which there is no networking
>software yet.  The searcher doesn't want to implement all of TCP, and sees
>"datagrams" as being easier, particularly on a single Ethernet.  Another
>common goal has been to get very high throughput by avoiding the "excessive
>overhead" of TCP, but Van Jacobsen's research has more or less laid that
>one to rest.  A third one has been "preservation of message boundaries".

Good summary.  Having made the mistake (no doubt through initial
fuzzy-headedness on my part), of having built an RPC system whose protocol
I called "datagram-oriented" (and which I now call "connection-oriented,
but designed with the knowledge that RPC is the application that wants
to use it" -- at least to people who might understand what I mean), I
try to be very careful when I say "datagram" these days.

Anyway, one other goal of some people in search of something other than
TCP is the reduction in the number of network messages that need to be
exchanged for short-lived connections (which often occur when you're
doing RPC), in particular eliminating some of the connection setup and
tear-down messages.  E.g., for the purposes of RPC, it sure would have
been nice if I could do something like send data (i.e., the remote call's
input parameters) in a SYN.  (I've never seen an implementation that
allows this; I can't point to the place in the TCP spec that disallows
it, but I imagine it is disallowed.)  Maybe it's not really so bad to
have the number of control messages be more than the number of
data-carrying messages in case I make one remote call to a server, but
my assumption is that the overall system will behave better if the number
of control-only messages is reduced.

--
                    -- Nat Mishkin
                       Cooperative Object Computing Operation
                       Hewlett-Packard Company
                       mishkin@apollo.hp.com