From owner-freebsd-hackers  Fri Nov 15 13:56:29 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id NAA19785
          for hackers-outgoing; Fri, 15 Nov 1996 13:56:29 -0800 (PST)
Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA19777
          for <hackers@freebsd.org>; Fri, 15 Nov 1996 13:56:23 -0800 (PST)
Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <16120(2)>; Fri, 15 Nov 1996 13:55:08 PST
Received: by crevenia.parc.xerox.com id <177557>; Fri, 15 Nov 1996 13:55:01 -0800
From: Bill Fenner <fenner@parc.xerox.com>
To: fenner@parc.xerox.com, terry@lambert.org
Subject: Re: Sockets question...
Cc: hackers@freebsd.org, jdp@polstra.com, scrappy@ki.net
Message-Id: <96Nov15.135501pst.177557@crevenia.parc.xerox.com>
Date: Fri, 15 Nov 1996 13:54:58 PST
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

Terry:
>Bill:
> Terry:
>> >So at the "read" interface, you *can* count on it arriving in the
>> >same sized chunks as you wrote it
>> 
>> No, you can *never* count on that, since non-blocking reads from a stream
>> socket return as much data as is available, which could be less than you
>> asked for.  See soo_read() (or soo_rw() in earlier BSD's) and soreceive().
>
>By default, the sockets are blocking.  You have to go out of your
>way to make them non-blocking (ie: loading the gun before you can shoot
>yourself in the foot).

Terry, STOP SPECULATING.  Look at the code.  soo_read() is what is called
by the read system call, and it calls soreceive().  soreceive() returns
whatever is waiting, up to what is requested, unless you set MSG_WAITALL.
soo_read() doesn't set MSG_WAITALL, so the semantics of read() on a
blocking socket is to return as much data is waiting, up to the amount
that was requested.

>But on a blocking socket, it doesn't make sense to have to issue multiple
>system calls to read chunks of a whole message when you aren't going to
>do anything with it until all the reads have been satisfied?

The CSRG apparently felt otherwise.

  Bill