Unix Technical Digest V1 #11

[Ron Heiby (The Moderator)]

Unix Technical Digest       Mon, 11 Feb 85       Volume  1 : Issue  11

Today's Topics:
                     Help (ipc question) (2 msgs)
----------------------------------------------------------------------

Date: 3 Feb 85 00:12:05 GMT
From: ronnie at mit-eddie.UUCP (Ronnie Schnell)
Subject: Help (ipc question)

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 with one read.  I then have to go through the trouble of seperating
these messages.  This isn't so bad, but sometimes (often) I will fill up
the server's buffer, and stuff will be lost.  Am I doing something wrong?
Is ipc supposed to do this?  If so, is there a way to have the user
wait until the server has read the message without implementing
my own protocal?
	#Ron
	(ronnie at mit-mc.arpa)
	(..decvax!genrad!mit-eddie!ronnie)

------------------------------

Date: 4 Feb 85 01:38:26 GMT
From: chris at umcp-cs.UUCP (Chris Torek)
Subject: Help (ipc question)

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 at umcp-cs		ARPA:	chris at maryland

------------------------------

End of Unix Technical Digest
******************************
-- 
Ronald W. Heiby / ihnp4!{wnuxa!heiby|wnuxb!netnews}
AT&T Information Systems, Inc.
Lisle, IL  (CU-D21)