Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

net: document net.Conn operation after deadline is exceeded #17982

Closed
dsnet opened this issue Nov 18, 2016 · 7 comments
Closed

net: document net.Conn operation after deadline is exceeded #17982

dsnet opened this issue Nov 18, 2016 · 7 comments
Labels
Documentation FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@dsnet
Copy link
Member

dsnet commented Nov 18, 2016

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

@dsnet dsnet added this to the Go1.8Maybe milestone Nov 18, 2016
@bradfitz
Copy link
Contributor

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 bradfitz modified the milestones: Go1.8, Go1.8Maybe Nov 21, 2016
@bradfitz
Copy link
Contributor

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?

@quentinmit quentinmit added the NeedsFix The path to resolution is known, but the work has not been done. label Nov 22, 2016
@gopherbot
Copy link

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

@gopherbot
Copy link

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

@mikioh
Copy link
Contributor

mikioh commented Nov 22, 2016

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

@dsnet
Copy link
Member Author

dsnet commented Nov 25, 2016

@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
Copy link
Member Author

dsnet commented Nov 26, 2016

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Documentation FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

No branches or pull requests

5 participants