Question regarding allowHalfOpen Option

[jasnell]

Node.js' socket API allows for a allowHalfOpen option whose behavior is simply defined as:

If allowHalfOpen=false, when a socket receives a fin from the peer, the socket will be automatically transitioned into a draining state where the writable side is closed, existing writes in the queue are permitted to drain, followed by a fin sent immediately when the queue is drained.

If allowHalfOpen=true, when a socket receives a fin from the peer, only the readable side of the socket is closed. The writable side remains open until the user code explicitly closes the stream.

At all times, the stream allows a writable-closed-readable-open state.

For Node.js sockets, the default is allowHalfOpen=false.

The key question here is whether this is something that y'all considered for direct sockets and ruled out, didn't consider at all, decided Node.js' behavior is wrong, etc.

[jasnell]

FWIW, one of the primary reasons Node.js defaults allowHalfOpen=false is to prevent resource leaks in the common case on the client side (e.g. for instance, if the user forgets to close explicitly or buggy logic stops explicit close), which is obviously not as much of a concern in browser cases than it is in server cases.

[GrapeGreen]

We had a very shallow discussion concerning TCP's behavior after receiving a fin packet and ruled in favor of half-open (i.e. readable stream closes gracefully, writable stream stays open as per the current implementation/spec). We could potentially support both cases, although I'd be curious to first learn how commonly this option is used in Node.js.

Offtop: has there been any progress with the New net/tls/udp API discussion thread? I see that it got closed due to inactivity some time ago, and I would potentially be interested in reviving it.