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: <2461@fortune.UUCP>
Date: Tue, 7-Feb-84 04:07:43 EST
Article-I.D.: fortune.2461
Posted: Tue Feb  7 04:07:43 1984
Date-Received: Thu, 9-Feb-84 13:36:49 EST
Sender: notes@fortune.UUCP
Organization: Fortune Systems, Redwood City, CA
Lines: 28

#R:allegra:-220500:fortune:11600053:000:1040
fortune!rpw3    Feb  7 00:45:00 1984

+--------------------
| From:  Peter Vanderbilt 
| 
| It would be convenient to be able to reliably send one message
| without going through the trouble (and overhead) of setting up
| a stream.
+--------------------

That's what the Xerox NS "Packet Exchange" protocol is all about.

Even so, you should be careful to set up your services to be idempotent.
Since any given packet may be lost/duplicated, it should be o.k. for a
given request (with the same tag/cookie/handle) so be acted on more
than once. Note that UNIX read's and write's have this property, if the
file offset ["lseek" pointer] is included in the request, and you don't
do a second operation 'til the first has succeeded.  (Unfortunately,
"open" and "close" are harder, without additional state in the server
that the simple protocol was designed to avoid in the first place.)

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