From owner-freebsd-hackers  Fri Nov 15 12:04:15 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id MAA12579
          for hackers-outgoing; Fri, 15 Nov 1996 12:04:15 -0800 (PST)
Received: from sumatra.americantv.com (sumatra.americantv.com [199.184.181.250])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA12566
          for <hackers@FreeBSD.org>; Fri, 15 Nov 1996 12:04:12 -0800 (PST)
Received: from right.PCS (right.pcs. [148.105.10.31]) by sumatra.americantv.com (8.7.6/8.7.3) with ESMTP id NAA11689; Fri, 15 Nov 1996 13:22:57 -0600 (CST)
Received: (jlemon@localhost) by right.PCS (8.6.13/8.6.4) id UAA28019; Fri, 15 Nov 1996 20:01:04 GMT
Message-Id: <199611152001.UAA28019@right.PCS>
Date: Fri, 15 Nov 1996 14:01:03 -0600
From: jlemon@americantv.com (Jonathan Lemon)
To: terry@lambert.org (Terry Lambert)
Cc: jgreco@brasil.moneng.mei.com (Joe Greco), terry@lambert.org,
        jdp@polstra.com, scrappy@ki.net, hackers@FreeBSD.org
Subject: Re: Sockets question...
References: <199611150414.WAA26986@brasil.moneng.mei.com> <199611151748.KAA26388@phaeton.artisoft.com>
X-Mailer: Mutt 0.48.1
Mime-Version: 1.0
In-Reply-To: <199611151748.KAA26388@phaeton.artisoft.com>; from Terry Lambert on Nov 15, 1996 10:48:35 -0700
Sender: owner-hackers@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

Terry Lambert writes:

> Otherwise, you have just un-formatted your transport contents.  8-(.

TCP streams are byte oriented, not record oriented.  There is no preservation
of record boundaries with TCP.

 
> > If you have a blocking read, select() returns true on a FD because one
> > byte is available, and you try a read(1000), will it block?
> 
> Yes.  It will block pending all 1000 bytes being available.

No it won't, if the FD is a socket.  It'll return as soon as sequenced data
is available from the TCP layer, with the additional constraint:

     SO_RCVLOWAT is an option to set the minimum count for input operations.
     In general, receive calls will block until any (non-zero) amount of data
     is received, then return with the smaller of the amount available or the
     amount requested.  The default value for SO_RCVLOWAT is 1.  If
     SO_RCVLOWAT is set to a larger value, blocking receive calls normally
     wait until they have received the smaller of the low water mark value or
     the requested amount.  [...]


> If you want to get technical, according to this description, if you are
> using a SOCK_STREAM, then a read on a blocking socket will act like a
> recv(2) or recvfrom(2) with flags MSG_WAITALL by default.

read(2), recv(2), and recvfrom(2) all call soreceive() for sockets.  read(2)
does NOT set MSG_WAITALL when calling soreceive().  Also:

         * If MSG_WAITALL is set but resid is larger than the receive buffer,
         * we have to do the receive in sections, and thus risk returning
         * a short count if a timeout or signal occurs after we start.

So MSG_WAITALL can also return a short count.


> Maybe you should be using SOCK_SEQPACKET instead of SOCK_STREAM?

That might be difficult.

     A SOCK_SEQPACKET socket [ .... ] is protocol specific, and presently 
     implemented only for PF_NS.  (PF_NS == Xerox Network Systems protocols)
--
Jonathan