Date: Thu, 14 Nov 1996 22:30:39 -0600 (CST) From: Joe Greco <jgreco@brasil.moneng.mei.com> To: karl@mcs.net (Karl Denninger) Cc: jgreco@brasil.moneng.mei.com, scrappy@ki.net, jdp@polstra.com, hackers@freebsd.org Subject: Re: Sockets question... Message-ID: <199611150430.WAA27067@brasil.moneng.mei.com> In-Reply-To: <199611150153.TAA23161@Mercury.mcs.net> from "Karl Denninger" at Nov 14, 96 07:53:20 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611150430.WAA27067>