Hello Alexey and Andi,
> > 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
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
> > 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?
> > 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
> > 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
> the window forcedly and drop the receiver into slow path, but that would
> 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
> to the fast path.
Andi, I noted already your idea about delivering a RST in this case. I
the above is the practical reason that makes implementing this difficult?
> > 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
> > 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)
> > blocks. I see that this also occurs on FreeBSD 4.8, Tru64 5.1B, HP/UX
> That's because the data is not discarded so the window fills.
Yes, I should perhaps have added that in the circumstances, blocking at
point is not surprising (to me).
> > and Solaris 8. Have I misunderstood Stevens, or has something changed
> > since the implementation he described (or was his statement wrong)? (In
> Probably Stevens was confused.
There seems to be a consensus emerging ;-).
+++ GMX - Mail, Messaging & more http://www.gmx.net +++
Jetzt ein- oder umsteigen und USB-Speicheruhr als Prämie sichern!