Path: utzoo!attcan!uunet!mtxinu!ed
From: ed@mtxinu.COM (Ed Gould)
Newsgroups: comp.unix.wizards
Subject: Re: preserving message boundaries
Message-ID: <871@mtxinu.UUCP>
Date: 2 Jun 89 00:39:25 GMT
References: <571@lehi3b15.csee.Lehigh.EDU> <8486@chinet.chi.il.us> <1165@muffin.cme.nbs.gov> <1220@muffin.cme.nbs.gov>
Reply-To: ed@mtxinu.COM (Ed Gould)
Organization: mt Xinu, Berkeley
Lines: 32

>There was some discussion earlier about preserving message boundaries,
>and I posted two functions that would do this (by encoding the length
>at the beginning) ...

>I pointed out that I used them on top of TCP (although they work over
>anything).  Someone wrote back that I should just be using send() and
>recv() as this is what they were intended to do.

>So I wrote a test program that [fails]

>recv() does not do atomic reads!  Indeed, the man page says nothing
>about it.  The man page for send() says something very cryptic about
>atomic writes - but even if it is atomic, it is worthless if recv()
>isn't.

send()/recv() can do atomic things *only* if the underlying protocol
supports them.  TCP does not, so there is no way for recv() to know
what was written by send().  If the underlying protocol were UDP,
then send/recv would be atomic.  As they would be, I presume, with
a procotol like SPP/XNS.

>By the way, I am using SunOS 4.0.1.  Should I report this to Sun?  (It
>is not clear from the man pages that this is incorrect behavior.)

This is not a bug, but a condition of the particular protocol (TCP).


-- 
Ed Gould                    mt Xinu, 2560 Ninth St., Berkeley, CA  94710  USA
ed@mtxinu.COM		    +1 415 644 0146

"I'll fight them as a woman, not a lady.  I'll fight them as an engineer."