jdd@allegra.UUCP (John DeTreville) (01/13/84)
When I read the 4.2 documentation, I get the impression that datagram
service under the UNIX domain is unreliable, with no indication being
guaranteed to the sender in the case of error. Is this true?
Cheers,
John ("That Wouldn't Be My Choice") DeTreville
Bell Labs, Murray Hillthomson@utcsrgv.UUCP (Brian Thomson) (01/19/84)
The easy answer is that UNIX-domain datagrams are unreliable because
they are full of bugs. The eye-for-the-future answer is that you get
indications of SOME errors (i.e. destination address is not a socket
or not a datagram socket) but not others.
In particular, if you send a message to a socket that doesn't have
sufficient buffer resources to hold it, the datagram is silently discarded.
At least, that's what I THINK happens. It's difficult to test because
of the bugs.
--
Brian Thomson, CSRG Univ. of Toronto
{linus,ihnp4,uw-beaver,floyd,utzoo}!utcsrgv!thomsonchris@umcp-cs.UUCP (02/01/84)
I'm not sure if people understand what allegra!jdd (if I remember
correctly) was saying.
His point is that UNIX IPC datagrams, in AF_UNIX, on 4.2, *are*
reliable. This is just a side-effect of the current implementation,
but they might have noted this in the manual, with something like:
"Oh by the way, it just so happens that right now, datagrams in
AF_UNIX are reliable. This may change and we don't recommend that
anyone rely on this. If you rely on this and it changes, that's
your tough luck."
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci
UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet: chris@umcp-cs ARPA: chris.umcp-cs@CSNet-Relaymccallum@opus.UUCP (02/01/84)
AF_UNIX datagrams under 4.2 are definitely NOT reliable. They
are effectively reliable if the reading process receives the datagrams
in a reasonable time, but if the reader is slow and the sender keeps
sending then datagrams are dropped. This can be demonstrated by
setting up a receiving process that receives a message then sleeps
a second and having a sending process that keeps sending. If part of
the data is a sequence number, the receiver will see that some messages
have been dropped. The sender does not see an error and never blocks
on the send.
Most applications that would use datagrams don't need strict reliability
and should be using an application dependent protocol to guarantee
reliablity.
There are other problems with the 4.2 AF_UNIX datagrams. Has anyone tried
to connect a datagram socket and then use it?
Doug McCallum
NBI, Inc.
{allegra,ucbvax,hao}!nbires!mccallumeric%cit-vax@sri-unix.UUCP (02/02/84)
From: Eric Holstege <eric@cit-vax> It is pointless to require reliable datagrams; the whole point of datagrams is that they need not be reliable. If you want a reliable channel, use a stream; you can simulate datagrams on a stream. Eric Holstege (eric@cit-vax)
pv.usc-cse%rand-relay@sri-unix.UUCP (02/03/84)
From: Peter Vanderbilt <pv.usc-cse@rand-relay>
It is pointless to require reliable datagrams; the whole point of
datagrams is that they need not be reliable. If you want a reliable
channel, use a stream; you can simulate datagrams on a stream.
It would be convenient to be able to reliably send one message without going
through the trouble (and overhead) of setting up a stream.eric%cit-vax@sri-unix.UUCP (02/04/84)
From: Eric Holstege <eric@cit-vax>
It is pointless to require reliable datagrams; the whole point of
datagrams is that they need not be reliable. If you want a reliable
channel, use a stream; you can simulate datagrams on a stream.
It would be convenient to be able to reliably send one message without going
through the trouble (and overhead) of setting up a stream.
In order to reliably send a datagram, one must have some indication that
the recipient is listening, as well as that he actually receives what he
is sent. This is tantamount to establishing a two-way connection, the
main inconvenience of streams relative to datagrams. Streams are more
general than datagram connections for the same reason that UNIX
byte-seekable files are more general than the record-seekable file types
beloved of VMS, etc. As for streams having more overhead, so do
byte-seekable files, but no one proposes that another file type,
512-byte-record files, be added to UNIX for the sake of efficiency. The
issue is the same, should the kernel give you the amount of data you
want to read, or should you be forced to read the amount it feels like
giving you.
Besides, pipes in 4.2 are implemented as IPC streams, with (if you
believe the performance figures) a substantial improvement over 4.1
pipes. Fast enough for me.
What I'd like to see is a library implementing something like VMS
mailboxes using sockets, with calling sequences that aren't as painful
to figure out as the socket stuff.
- Eric Holstege
eric@cit-vaxthomson@uthub.UUCP (Brian Thomson) (02/11/84)
Chris Torek writes:
"... UNIX IPC datagrams, in AF_UNIX, on 4.2, *are*
reliable. This is just a side-effect of the current implementation,
but they might have noted this in the manual, ..."
Just in case anyone is mislead by this, let me reiterate that
UNIX IPC datagrams, in AF_UNIX, on 4.2, *ARE NOT* reliable. As I posted
last month, there is no flow control. If you send a message to a
socket that doesn't have sufficient buffer resources to hold it,
the datagram is silently discarded.
The discussion has since waxed effusive, with lots of justification for
datagram unreliability in networks. A few also addressed the original
question, which asked why datagrams in the UNIX domain should be unreliable,
given that both endpoints of the communication are within the same processor.
It appears to me that there are three reasons:
1) So the AF_UNIX domain can, in the future, be compatibly
expanded via 'hidden' networking into a true inter-processor
IPC mechanism. UNIX datagrams could be directly implemented
as network datagrams, and all your old programs would still
work (but between processors now) because they didn't assume
any more reliability than the network is willing to offer.
2) Because SOCK_DGRAM means unreliable datagram, and shouldn't
mean different things in different domains.
3) The unreliability isn't gratuitous at all. I can think of
situations where I would want the packet to be discarded
if the receiving process isn't keeping up.
Reason #1 is a good one, and has already been widely discussed. Enough said.
Reason #2 smacks of being a head-in-the-clouds response. People who
want to send messages without implementing their own higher-level protocols,
and without having to set up SOCK_STREAM connections, might well grumble
that this is a case of ideals at the expense of functionality. But you
should remember that the Grand Plan for 4.x IPC includes FOUR socket types,
not two. SOCK_RDM, the "reliable datagram" socket type, is what those
users really want. And, if they had it, SOCK_DGRAM could remain blissfully
unreliable. So, rather than complain that AF_UNIX's SOCK_DGRAMs are
wrong, they should be complaining that SOCK_RDM is unimplemented. And
that is traceable to the lack of a reliable connectionless protocol in the
Internet domain.
Reason #3 represents the notion that SOCK_DGRAM sockets interact as loosely
as possible. Returning to the UNIX domain case, the question becomes
"What should the kernel do if the receiving socket's buffers are full?"
It can either throw the data away or wait for the buffers to drain. All
of SOCK_RDM, SOCK_SEQPACKET and SOCK_STREAM would wait. But if I want
to insulate my important server process from lazy or malicious clients,
I may prefer the first. If the process that asked for my service isn't
prepared to accept it, that's his problem and I don't want to be blocked
indefinitely by him. Note that this isn't quite the same as a SOCK_RDM socket
with the non-blocking option enabled, because I am still willing to wait
for my own socket's transmit buffers to drain (for example).
Still, I would claim that in most cases when you want connectionless,
easy-to-use UNIX domain IPC you are really asking for an RDM implementation.
--
Brian Thomson, CSRG Univ. of Toronto
{linus,ihnp4,uw-beaver,floyd,utzoo}!utcsrgv!thomson