Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site umcp-cs.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!ihnp4!zehntel!tektronix!decvax!genrad!panda!talcott!harvard!seismo!umcp-cs!chris
From: chris@umcp-cs.UUCP (Chris Torek)
Newsgroups: net.unix-wizards
Subject: Re: Help (ipc question)
Message-ID: <2981@umcp-cs.UUCP>
Date: Sun, 3-Feb-85 20:38:26 EST
Article-I.D.: umcp-cs.2981
Posted: Sun Feb  3 20:38:26 1985
Date-Received: Sat, 9-Feb-85 07:13:04 EST
References: <3548@mit-eddie.UUCP>
Distribution: net.unix-wizards
Organization: U of Maryland, Computer Science Dept., College Park, MD
Lines: 22

> I am trying to write a program using 4.2 ipc stuff.  What I have
> discovered is that when the client does more than one send before
> the server does its recv (read), the server will receive both (all
> 70) messages at once [...].  I then have to go through the trouble
> of sep[a]rating these messages.  [...] Am I doing something wrong?
> Is ipc supposed to do this?

This is what's meant by ``byte stream'' or ``atomic'' protocols.  If
you have a stream protocol, it presents no record boundaries; if you
want any, you have to make them up yourself.  If you're using an
atomic protocol, then there is something inherent in the protocol
that makes each message a single unit.

TCP is a stream protocol.  UDP is a datagram (atomic) protocol.
However, UDP is not reliable (messages can [i.e., will] be dropped or
duplicated or reordered).  If you're working on a single machine you
can use AF_UNIX SOCK_DGRAM sockets to get a 99% reliable datagram
protocol.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251)
UUCP:	{seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@maryland