Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site fortune.UUCP Path: utzoo!watmath!clyde!floyd!harpo!ihnp4!fortune!rpw3 From: rpw3@fortune.UUCP Newsgroups: net.unix-wizards Subject: Re: UNIX IPC Datagram Reliability under - (nf) Message-ID: <2460@fortune.UUCP> Date: Tue, 7-Feb-84 04:07:17 EST Article-I.D.: fortune.2460 Posted: Tue Feb 7 04:07:17 1984 Date-Received: Thu, 9-Feb-84 13:36:28 EST Sender: notes@fortune.UUCP Organization: Fortune Systems, Redwood City, CA Lines: 56 #R:allegra:-220500:fortune:11600052:000:2831 fortune!rpw3 Feb 6 20:41:00 1984 In response to Ken Almquist: 1. As Eric said, if you want reliable UNIX domain communication, use streams, which provide that service. IP datagrams are by definition unreliable. [But... if you are using UNIX domain as IPC, see below.] 2. In general, what makes good IPC within a single (tightly-coupled multi-)processor does not make a good (loosely-coupled network) message system, and vice-versa. The tradeoffs are too different. Trying to use one where the other fits is awkward at best. (Microsecond busy-waits are often appropriate in the former case; sleeps of seconds or minutes in the latter.) A good fast low-overhead IPC can sometimes be one of the mechanisms on which networking is built (see the CMU "Hydra/C.mmp" book), but even so one must be careful about synchronization and queueing. (It is not yet clear to me that S-5 IPC is fast/cheap enough.) Simple/clean IPC is rarely achieved on top of networking (but see the literature on "Remote Procedure Calls".) When the reason for having multiple processes in the first place was to "solve" some synchronization/event-waiting problem with multi-programming WITHIN a single process, the lack of adequate sync/event mechanisms often comes back to bite the IPC user. Whether it's "software interrupts on events" or the 4.2 "select", SOME form of "tell-me-about-the-first-interesting-event" seems necessary for real concurrency. Having a forest of processes, each waiting on one specific event, is useful only if the process sleep/wake time is VERY small, and efficient fine-grained locks on shared-memory data are available. (Again, see the "Hydra" book, conversely also see Holt's "Concurrent-Euclid/UNIX/Tunis".) I guess I'm trying to say, "Look again at why you're using UNIX domains at all." Preparation for future networking? [O.k., fine] ... or as a type of IPC? If IPC, would you rather have some other kind? [Nothing wrong with "making do", but one needn't celebrate the crutch.] 3. A close reading of the X.25 standard will reveal that a "RESET" message is permitted from the network or either party at any time, with no synchronization with the other party. (Remember, X.25 is a network ACCESS protocol, not a peer-peer protocol.) "RESET" does NOT drop the connection, it just resets ("drops") the sequence numbers. This can cause data to be lost and/or duplicated unless a higher level stream protocol (with its own sequence numbers) is used on top of X.25 connections. Networks may issue "RESET" at any time, such as when load-shedding data to relieve buffer congestion. Rob Warnock UUCP: {sri-unix,amd70,hpda,harpo,ihnp4,allegra}!fortune!rpw3 DDD: (415)595-8444 USPS: Fortune Systems Corp, 101 Twin Dolphins Drive, Redwood City, CA 94065