Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!floyd!harpo!seismo!hao!hplabs!sri-unix!eric@cit-vax From: eric%cit-vax@sri-unix.UUCP Newsgroups: net.unix-wizards Subject: Re: UNIX IPC Datagram Reliability under 4.2BSD Message-ID: <16399@sri-arpa.UUCP> Date: Fri, 3-Feb-84 23:24:38 EST Article-I.D.: sri-arpa.16399 Posted: Fri Feb 3 23:24:38 1984 Date-Received: Thu, 9-Feb-84 06:16:39 EST Lines: 30 From: Eric HolstegeIt 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-vax