Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site hou3c.UUCP Path: utzoo!watmath!clyde!burl!hou3c!ka From: ka@hou3c.UUCP (Kenneth Almquist) Newsgroups: net.unix-wizards Subject: Re: UNIX IPC Datagram Reliability under - (nf) Message-ID: <235@hou3c.UUCP> Date: Fri, 3-Feb-84 20:54:51 EST Article-I.D.: hou3c.235 Posted: Fri Feb 3 20:54:51 1984 Date-Received: Wed, 8-Feb-84 04:55:30 EST References: <2392@fortune.UUCP> Organization: Bell Labs, Holmdel, NJ Lines: 55 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.