From owner-freebsd-hackers Thu Nov 14 19:01:31 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA06264 for hackers-outgoing; Thu, 14 Nov 1996 19:01:31 -0800 (PST) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA06255 for ; Thu, 14 Nov 1996 19:01:23 -0800 (PST) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.7.6/8.7.3) with ESMTP id SAA12064; Thu, 14 Nov 1996 18:58:11 -0800 (PST) Message-Id: <199611150258.SAA12064@austin.polstra.com> To: Karl Denninger cc: scrappy@ki.net, jgreco@brasil.moneng.mei.com, hackers@FreeBSD.org Subject: Re: Sockets question... 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> Date: Thu, 14 Nov 1996 18:58:11 -0800 From: John Polstra Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > 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