[net.unix-wizards] Datagrams Under UNIX IPC Domain in 4.2BSD

jdd@allegra.UUCP (John DeTreville) (01/17/84)

Last week I posted a query about whether datagrams were really unreliable
under 4.2BSD's UNIX IPC domain.  I haven't received any useful replies, so
let me rephrase my question.

Let's say I have some typical set of communicating processes on some
uniprocessor, and I would like to have them communicate via message-passing.
Fine, I think, I'll use sendmsg(2) and recvmsg(2) and send datagrams in the
UNIX IPC domain.  Unfortunately, by definition, datagrams can be lost
without any indication to the sender or receiver, and this is probably not
what I had in mind in my original formulation.

Now, I understand how the Berkeley people wanted to have a pleasingly
orthogonal design, with the same definition for datagrams in any domain, but
this just doesn't seem very \useful/, which is another criterion one could
apply.  Offhand, I can't think of any other operating system providing
message-passing on a uniprocessor that chooses to give no indication of
failure.  One can work around such a feature, but at quite a potential cost
in clarity and/or performance.

(Of course, you can argue that one gains a certain sort of generality when
using datagrams thus, because it makes it easier to move the application
into a distributed environment, where these semantics are less avoidable.
In the particular application I'm concerned with, though, this turns out not
to be a factor.)

The question is, then, whether this is really as poor a design as it seems.

Cheers,
John ("It's Getting Late So I'm Going Home Now") DeTreville
Bell Labs, Murray Hill

gwyn%brl-vld@sri-unix.UUCP (01/21/84)

From:      Doug Gwyn (VLD/VMB) <gwyn@brl-vld>

User datagrams indeed are not useful for reliable communication, unless
you layer around them a reliable transport protocol.  The intention of
datagrams is to provide a cheap service for applications where delivery
of messages need NOT be guaranteed.  Most applications require a more
reliable message-passing mechanism.

Some possible datagram applications are:
	Net information servers, such as the "rwho" daemon.  It may not
	be too important to get EVERY update for such information so
	long as nobody trusts the absolute accuracy of the net status.

	Sampling data acquisition.  It may not be necessary to collect
	EVERY datum if you are randomly sampling something.

	System clock rate adjustments in a network.  Generally some
	slop in the relative clock rates must be permitted; it is okay
	to miss a few packets from the master time server so long as
	the rate is eventually tweaked on each host.

	Junk mail.  It is more important to have the transport done
	cheaply than it is to ensure delivery.