Hello,
I've done quite some searching, but have so far not found an answer
to the question of why does the behaviour described below occur on
Linux...
According to SUSv3, if we perform a shutdown(fd, SHUT_RD) on a socket,
then further reads on that socket should be disabled. In the AF_UNIX
domain, all is fine -- things operate as I expect. However, for
TCP sockets, things are different (tested on 2.2.14, and 2.4.20):
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 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.
I thought that most implementations (other than Linux) did things
this way, but I've just now gone and tested things on Solaris 8,
and it seems to behave in the same way as Linux.
I've read the relevant source code to confirm the anomalous behaviour
described here. But, why do things happen in this way on Linux?
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 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
blocks. I see that this also occurs on FreeBSD 4.8, Tru64 5.1B,
HP/UX 11 and Solaris 8. Have I misunderstood Stevens, or has
something changed since the implementation he described
(or was his statement wrong)? (In the AF_UNIX domain on Linux, the
peer gets SIGPIPE/EPIPE if it keeps writing after a local SHUT_RD.)
Thanks
Michael
--
+++ GMX - Mail, Messaging & more http://www.gmx.net +++
Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage!
|