TCPConn.Shutdown

[Brad Fitzpatrick]

Any objections to adding a TCPConn.Shutdown method?

I see http://code.google.com/p/go/issues/detail?id=2122 and linked threads, but those are about people wanting to *not* call shutdown.  I *do* want to shutdown (for write, in my case)

I can do it with syscall, but not portably (windows has a handle, not an fd int).

Yay nay meh?

[Dave Cheney]

SGTM. Would this shutdown both 'sides' of the tcp connection, or just
the outgoing side ?

[Mikio Hara]

yay.

[Brad Fitzpatrick]

I need to close for writing and send a FIN but keep reading.

I know about Close.

I asked for adding a method to TCPConn specifically. TCP supports this.

[Dave Cheney]

java.net.Socket has a pair of these methods, shutdownInput and
shutdownOutput, you should probably add both for completeness.

[Russ Cox]

On Tue, Sep 27, 2011 at 21:32, Brad Fitzpatrick <brad...@golang.org> wrote:

I need to close for writing and send a FIN but keep reading.

I know about Close.

I asked for adding a method to TCPConn specifically. TCP supports this.

TCP supports this but I assert that protocols

that require it are broken.  What protocol do

you need this for?

Russ

[Paul Borman]

Why do you assert those protocols are broken?  They are informing the other side that no further read or writes will happen so if the other side does do a write or read it can fail locally as well as no longer track that state.  A client which does a bit of chatter with a server to request data and then simply reads the data should shutdown writes once the request is finished and the server should shut down reads when it no longer expects them.  It is a perfectly fine thing to do in networking.  (But most programmers are lazy.)

    -Paul

[Mikio Hara]

On Wed, Sep 28, 2011 at 11:27 AM, Russ Cox <r...@golang.org> wrote:

> TCP supports this but I assert that protocols
> that require it are broken.  What protocol do
> you need this for?

For example, some research protocols such as BMP.
<http://tools.ietf.org/html/draft-ietf-grow-bmp-05>

<quote>
The monitored router MAY take steps to prevent the monitoring
station from sending data (e.g. by half-closing the TCP session
or setting its window size to zero) or it MAY silently discard any
data erroneously sent by the monitoring station.
</quote>

There is a space even though very small and optional.