net: document net.Conn operation after deadline is exceeded

[dsnet]

The current phrasing on net.Conn.SetDeadline is:

A deadline is an absolute time after which I/O operations fail with a timeout (see type Error) instead of blocking. The deadline applies to all future and pending I/O, not just the immediately following call to Read or Write.

An idle timeout can be implemented by repeatedly extending the deadline after successful Read or Write calls.

A zero value for t means I/O operations will not time out.

I'm debugging some non-compliant implementations of net.Conn due to the clarification made in (CL/30164). While fixing them, I noticed another discrepancy of some net.Conn implementations as compared to net.TCPConn and would like some clarification on expected behavior.

The net.TCPConn implementation allows a deadline to be exceeded, which unblocks any pending IO operations. However, after an timeout, it also allows the user to extend the deadline to be in the future, essentially allowing IO operations to function again.

In some of the implementations I'm fixing, once the deadline has been exceeded, the underlying connection is destroyed and it does not matter if the deadline is set to be in the future again; all IO operations henceforth are dead.

Is "refreshable" deadlines an expected behavior of net.Conn? Does any logic in the standard library depend on it?

/cc @bradfitz @ianlancetaylor

[bradfitz]

Is "refreshable" deadlines an expected behavior of net.Conn?

In general, if Unix and Windows's TCPConn does X, we try to make all implementations (including nacl's and other internal implementations) also do X.

Does any logic in the standard library depend on it?

I can't think of anything in std that depends on that behavior, but other things in the broader ecosystem almost certainly do.

I'd err on the side making the internal implementations act like the std TCPConn on linux (and presumably windows).

We could add a CL documenting it if you'd like, but it'd need a test too.

Or we could start with just a test out of curiosity and see what all the current implementations do, even if we don't submit the CL.

[bradfitz]

Does any logic in the standard library depend on it?

I can't think of anything in std that depends on that behavior, but other things in the broader ecosystem almost certainly do.

Actually, net/http does exactly that.

So we should document this.

Want to send a doc CL, @dsnet?

[gopherbot]

CL https://golang.org/cl/33473 mentions this issue.

[gopherbot]

CL https://golang.org/cl/33472 mentions this issue.

[mikioh]

Is there any reason not to care of net.PacketConn too?

[dsnet]

@mikioh, for net.PacketConn.ReadFrom, what is the behavior when the buffer provided is not large enough to read the entire packet? Does the remaining payload get dropped? Does the next call to ReadFrom finish off the packet?

On the flip-side, what happens when the buffer provided to WriteTo is larger than the MTU. Should the method implicitly chunk the input into multiple packet-sized chunks?

[dsnet]

Since this issue was originally about deadlines. I'll commit the CL as is. I'll file a separate issue for PacketConn and packet sizes to fix in Go 1.9.