From: barmar@alum.mit.edu
In article ,
Jorgen Grahn wrote:
> On Fri, 28 Aug 2009 16:39:33 -0700 (PDT), David Schwartz
> wrote:
> > On Aug 28, 1:41 pm, Jorgen Grahn wrote:
> >
> >> What is the BSD socket call shutdown(fd, SHUT_RD) supposed to do to
> >> a TCP socket, really? I have a short program where I do
> >
> > Doing a shutdown(SHUT_RD) on a TCP socket is not sensible. You have to
> > remember, that 'shutdown' is protocol-neutral and is designed to
> > support protocols that have a meaningful way to shut down the read
> > end.
>
> OK; I just thought TCP was such a protocol. Making read()s fail and
> telling the peer on the other side that the socket RX buffer is full
> seemed right to me -- given that I thought shutdown() on a TCP socket
> kind of transformed it from two octet streams into just one.
The problem with this is that most TCP APIs don't provide any way to
find out that the receive buffer is full.
The main value of shutdown() on a TCP socket is with SHUT_WR. This
sends a FIN but doesn't close the connection, which transforms it into a
half-open connection. This is useful for protocols where the server
reads until EOF, processes the data, and sends back a response. The
example I like to give is a network version of the sort(1) command (you
could actually do this simply with an inetd.conf entry that invokes
/usr/bin/sort).
>
> On the other hand, now that you mention it I cannot quite see the
> purpose. It doesn't matter if I shutdown or not; I have to design the
> protocol between the two applications in the same way.
There's some value to sending RST. If you call shutdown(SHUT_RD) when
the remote end is supposed to be done sending you data, then if it
actually does send something it indicates a bug, and it makes sense to
kill the connection.
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
