UNIX IPC Datagram Reliability under - (nf)

[Kenneth Almquist]

In response to Rob Warnock's defense of unreliable datagrams:

I have nothing against networks (like the ARPANET) that are based upon
unreliable datagrams, but I don't like the idea of lots of user
programs using unreliable datagrams.  They force each user to provide
for retransmission of lost packets, so there will be a lot of
reinventing the wheel.  And since testing the effectiveness of error
recovery schemes is rather difficult, probably many of these
retransmission schemes will be tested inadequately or not at all.  The
result is likely to be programs that work most of the time but suffer
occasional mysterious failures.

Ideally I would like an interprocess communication mechanism that would
handle all errors for the user.  It is not possible for any
communications protocal to recover if either the data network or the
program being communcated dies, so the application program must be
informed of these errors and must be programmed to deal with them; but
I would require the protocal to recover from other errors types of
errors.  Three possible objections to this:

	1)  It is unimplementable.
No.  Stream sockets meet these requirements.

	2)  It is too inefficient to implement.
I believe that some of the most heavily used protocals on the
Arpanet, such as smtp (mail) and ftp (file transfer) are built on top
of tcp rather than being built directly on ip (unreliable datagrams),
so presumably the Arpanet developers find the cost of doing so
acceptable.  When the two processes are on one machine it is easy to
make communication reliable, and it's also more efficient to do
so than to have programs constantly setting alarm signals to determine
whether the programs they are talking to have gone away.  The cost of
setting up a connection probably makes stream sockets unacceptable for
some applications, but that is a problem with streams rather than with
the concept of reliable communications.  The V operating system, for
example, provides efficient interprocess communication without
requiring a "connection" to be established first.

	3)  Retransmission is not good for real time applications such
	    as voice or time of day.

True, but UNIX is not good for real time applications either.  Nor are
unreliable datagrams necessarily good either; they may arrive out of
order after arbitrary delays.
					Kenneth Almquist


P. S.  While I'm not an expert on X.25, I've never heard anyone call it
unreliable before.  It doesn't have dynamic routing on a per message
basis, so if a link goes down anybody who has virtual circuts over the
link looses them, if that's what you mean.  However, a protocal does
not need end to end acknowledgements to avoid losing data.  The level 2
protocals on each link ensure that no data is lost.  If a node crashes
then of course any data in its memory is lost but that is irrelevant
since the virtual circut has been lost anyway.