From owner-freebsd-hackers  Thu Nov 14 20:33:39 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id UAA11009
          for hackers-outgoing; Thu, 14 Nov 1996 20:33:39 -0800 (PST)
Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA11001
          for <hackers@freebsd.org>; Thu, 14 Nov 1996 20:33:33 -0800 (PST)
Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id WAA27067; Thu, 14 Nov 1996 22:30:39 -0600
From: Joe Greco <jgreco@brasil.moneng.mei.com>
Message-Id: <199611150430.WAA27067@brasil.moneng.mei.com>
Subject: Re: Sockets question...
To: karl@mcs.net (Karl Denninger)
Date: Thu, 14 Nov 1996 22:30:39 -0600 (CST)
Cc: jgreco@brasil.moneng.mei.com, scrappy@ki.net, jdp@polstra.com,
        hackers@freebsd.org
In-Reply-To: <199611150153.TAA23161@Mercury.mcs.net> from "Karl Denninger" at Nov 14, 96 07:53:20 pm
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> > Are you checking the return value from write() to make sure it actually
> > thinks that N bytes were _written_?
> > 
> > ... JG
> 
> Uh, hang on a second...
> 
> Are you saying that the behavior of a *TCP* connection is such that you
> would expect to see a write(2) call to the socket come back with a short
> count for any reason other than the remote having closed or some other 
> kind of transport error (ie: host unreachable, etc)?

Yes: a nonblocking socket write will most definitely display this
behaviour.

This allows a server application written with select() to continue to
service other connections.  Basically you use code something like this:

char *outqueue[9999];
char *outcurrent = NULL;

int main()
{
	int my_fd;
	fd_set fds;
	while (1)
		if (outcurrent)
			FD_SET(my_fd, &fds)
		select(a, fds, c, NULL)
		if (FD_ISSET(my_fd, &fds)) {
			writemore(my_fd);
		}
		if (want_to_output_something) {
			writetofd(my_fd);
		}
}

writemore(fd)
{
	int rval;
	rval = write(fd, outcurrent, strlen(outcurrent));
	if (rval != strlen(outcurrent)) {
		outcurrent += strlen(outcurrent) - rval;
	} else {
		outcurrent = pop_entry(outqueue);
	}
}

writetofd(fd)
{
	push_entry(outqueue, string);
}

Or something sorta like that.  Hopefully you see the idea...  you can
keep writing data as space allows.

Please excuse the horrid pcode.

> That may well be technically *legal*, but its *NOT* the behavior that a LOT 
> of applications depend on, nor is it behavior I've seen from *ANY* other Unix
> system at any time in the past five years!

I see it all the time :-)  You just generally do not see it on blocking
sockets...

I take that back.  You will see it if you get a signal.  Try writing lots
of data over a slow link...  and receive a signal.  Bam.

> Now UDP can (and does) come back with short counts if buffer space is low.
> And we all know that read()s can return short counts (and frequently do).
> 
> I'm questioning write(2) behavior to TCP sockets here.

"Be conservative in what you expect of the system, liberal in what you 
 accept."  (An applicable rewrite of an old rule.)

... JG