Path: utzoo!attcan!uunet!zaphod.mps.ohio-state.edu!mips!dimacs.rutgers.edu!aramis.rutgers.edu!athos.rutgers.edu!hedrick
From: hedrick@athos.rutgers.edu (Charles Hedrick)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Reliable Datagram ??? Protocols
Message-ID: <Oct.28.20.22.22.1990.709@athos.rutgers.edu>
Date: 29 Oct 90 01:22:24 GMT
References: <9010231728.AA03948@braden.isi.edu> <12632159446.18.BILLW@mathom.cisco.com>
Organization: Rutgers Univ., New Brunswick, N.J.
Lines: 23

Since TCP handles all errors, flow control, etc., about all your
trivial framing protocol needs to be is a byte count followed by the
data.  As long as your TCP implementation pushes every write (which is
typical of those that I know), this is about all you need.  In order
to catch coding errors, it's probably a good idea to include some way
of catching missynchronization, like some tacking on a -1 word at the
end of each message.

The esthetics of this do not bother me.  Converting messages to
streams and back will be a no-op in the simple case, and useful in
other cases.  That is, if you do single query and response, TCP will
simply send off your packets one by one, handling only the sorts of
issues you'd really rather not have to handle for yourself, such as
retransmission.  If you send more than one datagram in a given
direction (e.g. you respond to a query with lots of data), then
combining datagrams, sequencing, etc., are useful.  If TCP were really
a high-overhead thing, I'd worry about this, but lots of smart people
are putting lots of time into optimizing TCP.  They have almost
certainly done a better job than you will do.  The main places I
recommend avoiding TCP are when queries are being sent to varying
destinations, e.g. named, or when you need to use broadcasts.
And frankly I sometimes think it would have been better to have
done named only over TCP.