Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!sun-barr!cs.utexas.edu!uunet!cme!libes
From: libes@cme.nbs.gov (Don Libes)
Newsgroups: comp.unix.wizards
Subject: Re: preserving message boundaries
Summary: Is recv() supposed to be atomic?
Message-ID: <1220@muffin.cme.nbs.gov>
Date: 31 May 89 17:41:45 GMT
References: <571@lehi3b15.csee.Lehigh.EDU> <8486@chinet.chi.il.us> <1165@muffin.cme.nbs.gov>
Organization: National Institute of Standards and Technology
Lines: 55

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).  Namely:

> 	sized_write(fd,buffer,nbytes) - just like write()
> 	sized_read(fd,buffer,nbytes) - just like read() except that
> 					it returns what was written
> 					by one call to sized_write()

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 loops, writing 2**n bytes, with n=n+1
each time through the loop.  Another program reports what is being
atomically read.

Using sized_read(), it says:

reading 1 chars
reading 2 chars
reading 4 chars
reading 8 chars			[everything looks hunky-dory here]
reading 16 chars
.
.  [obvious lines omitted]
.
reading 65536 chars
reading 131072 chars
reading 262144 chars

-----------------------------------------------------------------------
Using recv() it says:

reading 1 chars
reading 2 chars
reading 3072 chars		<--- ????!?!
reading 1020 chars		<--- ????!?!
reading 4096 chars		<--- ????!?!
reading 4096 chars
reading 4096 chars
reading 4096 chars
.
.  [and so on]
.
---------------------------
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.

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.)

Don Libes          libes@cme.nbs.gov      ...!uunet!cme-durer!libes