UNIX IPC Datagram Reliability under - (nf)

[rpw3 at fortune.UUCP]

#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