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... Message-ID: <199611152001.UAA28019@right.PCS> In-Reply-To: <199611151748.KAA26388@phaeton.artisoft.com>; from Terry Lambert on Nov 15, 1996 10:48:35 -0700 References: <199611150414.WAA26986@brasil.moneng.mei.com> <199611151748.KAA26388@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611152001.UAA28019>