> From: Stelian Pop <stelian.pop@fr.alcove.com>
> Date: Fri, 5 Apr 2002 12:55:09 +0200
>
> > * client socket receives a TCP reset
>
> How is the client socket supposed to know it received a TCP reset
> (I am talking from the application point of view, not the kernel...) ?
>
> You may find out by attempting to read data, or you may use the
> extended IP error reporting Linux has.
In the client, I've added a read(fd, buf, 1) just after the write,
and rerun:
client server
... ...
shutdown()
...
lsof will shown the client socket being in CLOSE_WAIT at this point
...
write(fd, buf, 5) = 5
read(fd, buf, 1) = 0
...
exit(0)
exit(0)
As you can see, read() doesn't return any error, just 0 to
indicate end-of-file (seems correct interpretation of remote
shutdown here), but it doesn't report any error from the
precedent write... Bug ?
> But all of this is irrelevant. When a server closes and says "send me
> no more data", this implies that the server told the client it doesn't
> want any more data.
Perfectly valid but only if the 'applicative close' has reached the
other end. If it's still queued in TCP buffers, the client may not
have received yet that close... I thought that this was the only
reason that shutdown() existed at all: flush the buffers preparing
an imminent close...
> If the client sends data, this is a gross fatal
> error, so TCP resets in FIN_WAIT{1,2} states.
>
> RFC 793 originally specified to queue the data, RFC 1122 is where
> the current behavior is defined.
Thanks for the pointer.
Stelian.
-- Stelian Pop <stelian.pop@fr.alcove.com> Alcove - http://www.alcove.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/