Re: shutdown() and SHUT_RD on TCP sockets - broken?
From: <hidden>
Date: 2003-07-09 10:11:19
Hello Alexey and Andi, [Alexey]
quoted
blocks. I see that this also occurs on FreeBSD 4.8, Tru64 5.1B, HP/UX 11 and Solaris 8. Have I misunderstood Stevens,Most likely, it is that rare case when Stevens forgot to check the statement.
yes, it cerainly doesn't correspond to any current implementation that I could find anyway. I should of course have added that (as you are probably well aware) SUSv3 is vague but does say: SHUT_RD Disables further receive operations. which suggest that we shouldn't be able to read any more. It seems to me that the only ways of satisfying that requirement are to either discard data (a la Stevens) or send an RST to the writing peer (more on that in a moment) so that it stops sending.
From viewpoint of TCP the behaviour described in Stevens' book is highly unnatural. SHUT_RD on TCP does not make any sense.
A while back I had some communication with Andi Kleen on this point, and he suggested that the TCP could send an RST in this case, much as occurs if the reader close()s the socket. Is this not a starter? (Maybe not, for the reasons Andi outlined in his mail to this list -- quoted below.)
quoted
described here. But, why do things happen in this way on Linux?Actually, you could check one more thing. What does happen after freebsd 4.8 returns 0 on read()? Does it open window eventually?
I'm not quite sure what you mean here. Can you elaborate on the what type of experiment I should perform and what you expect I might see? [Andi]
quoted
1. If we perform a read() on the socket and there is no data, then 0 (EOF) is (immediately) returned. (This is what I expected.) 2. However, the peer can still write() to the socket, and afterwards we can read() that data from the socket, even though the reading half of
the
quoted
socket should be shut down. Instead of this behaviour, I expected the read() to continue to return 0 as in point 1. This is what we see for example in FreeBSD 4.8, Tru64 5.1B, and HP/UX 11.The problem is that it adds a new check to the input path. It's not clear how the check can be done outside the fast path (one way would be to
shrink
the window forcedly and drop the receiver into slow path, but that would
be
a severe protocol violation if the shrunk window leaks out with some ACK). I don't think it's a good idea to add a check for such an obscure
situation
to the fast path.
Andi, I noted already your idea about delivering a RST in this case. I assume the above is the practical reason that makes implementing this difficult?
quoted
3. (A side point.) Looking at Stevens UNPv1, p161, there is a statement that after a SHUT_RD, "any data for a TCP socket is acknowledged and
then
quoted
silently discarded". This implies to me that the sender could keep on writing to the socket and never block. However, on Linux, if the peer keeps sending to a socket, then eventually (the channel is filled and)
it
quoted
blocks. I see that this also occurs on FreeBSD 4.8, Tru64 5.1B, HP/UX
11
That's because the data is not discarded so the window fills.
Yes, I should perhaps have added that in the circumstances, blocking at this point is not surprising (to me).
quoted
and Solaris 8. Have I misunderstood Stevens, or has something changed since the implementation he described (or was his statement wrong)? (InProbably Stevens was confused.
There seems to be a consensus emerging ;-). Cheers, Michael --
+++ GMX - Mail, Messaging & more http://www.gmx.net +++
Jetzt ein- oder umsteigen und USB-Speicheruhr als Prämie sichern!