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