> From: Felipe Gasper <felipe@xxxxxxxxxxxxxxxx>
> Sent: Thursday, 3 November, 2022 10:43
> >
> > And your description looks wrong anyway: shutdown(SHUT_RD) has
> > implementation-defined behavior for TCP sockets (because TCP does not
> > announce the read side of half-close to the peer), and on Linux causes
> > blocked receives and subsequent receives to return 0 (according to references
>
> perl -MSocket -MIO::Socket::INET -e'my $s = IO::Socket::INET->new( Server =>
> 1, Listen => 1 ) or die; my $port = $s->sockport(); my $c = IO::Socket::INET-
> >new("localhost:$port") or die; syswrite $c, "hello"; my $sc = $s->accept();
> shutdown($sc, SHUT_RD); sysread $sc, my $buf, 512 or die $!; print $buf'
>
> ^^ The above, I believe, demonstrates to the contrary: the read buffer is
> populated prior to shutdown and drained afterward.
As I noted, I hadn't tested it. The Linux man page is ambiguous:
If how is SHUT_RD, further receptions will be disallowed.
It doesn't define "receptions". It's entirely possible that SHUT_RD will cause the stack to reject further application data (i.e. packets that increment the sequence number for anything other than ACK) from the peer, but permit the socket owner to continue to receive already-buffered data. That's arguably a poor implementation, and not what the man page appears to imply. And it looks to be in conflict with the Single UNIX Specification Issue 7 (not that Linux claims to be UNIX-conformant), which states that SHUT_SD "Disables further receive operations"; "operations" certainly seems to refer to actions taken by the caller, not by the peer.
There is a fair bit of debate about this online, and a number of people opine that the Linux behavior is correct, and SUS (they often refer to "POSIX", but POSIX has been superseded by SUS) is wrong. Others disagree.
The Linux kernel does take some action for a TCP socket that has SHUT_RD requested for it, but the behavior is not simple. (One SO comment mentions it causes it to exit the read loop in tcp_splice_read(), for example.) I'd be leery about relying on it.
I'm not sure how shutdown(SHUT_RD) is useful in the case of a TCP socket being used for TLS, to be perfectly honest. If the application protocol delimits messages properly and is half-duplex (request/response), then one side should know that no more data is expected and the other can detect incomplete messages, so there's likely no issue. If not, there's no way to guarantee you haven't encountered an incomplete message in bounded time (FPL Theorem applies). SHUT_RD does not signal the peer, so the peer can still get a RST if it continues to send. Perhaps I'm missing something, but I don't see what failure mode is being avoided by using SHUT_RD.
--
Michael Wojcik
