Date: Thu, 14 Nov 1996 18:58:11 -0800 From: John Polstra <jdp@polstra.com> To: Karl Denninger <karl@Mcs.Net> Cc: scrappy@ki.net, jgreco@brasil.moneng.mei.com, hackers@FreeBSD.org Subject: Re: Sockets question... Message-ID: <199611150258.SAA12064@austin.polstra.com> In-Reply-To: Your message of "Thu, 14 Nov 1996 20:46:55 CST." <199611150246.UAA13803@Jupiter.Mcs.Net> References: <199611150246.UAA13803@Jupiter.Mcs.Net>
next in thread | previous in thread | raw e-mail | index | archive | help
> I have an application which sends a query to a back-end server -- and that
> server can return literally hundreds of KB of data in response.
>
> On very long responses, it just STOPS.
>
> The writing end thinks it wrote all of the data, netstat -an shows nothing
> in the socket buffers, the reader is waiting in read() for more data (it
> never saw the end marker, and in fact never saw more than half of the
> response!)
If the socket is not in non-blocking mode, and you do a write(2) of N
bytes to it, and the write call returns anything other than -1 or N,
then that is a bug.
If the sending socket returns N, but not all of the data gets to
the receiving socket, then that is either a bug or a network problem.
>From write(2):
When using non-blocking I/O on objects such as sockets that are subject
^^^^^^^^^^^^
to flow control, write() and writev() may write fewer bytes than request-
ed; the return value must be noted, and the remainder of the operation
should be retried when possible.
OK, it doesn't come right out and say directly that it _won't_ do that
when using blocking I/O. But that is the implication. And it is the
historical behavior. And it is the behavior that probably 90% of
network applications are written to expect.
--
John Polstra jdp@polstra.com
John D. Polstra & Co., Inc. Seattle, Washington USA
"Self-knowledge is always bad news." -- John Barth
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611150258.SAA12064>