-
Notifications
You must be signed in to change notification settings - Fork 24
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
fix: don't keepalive when the connection is busy #16
Conversation
We wouldn't permanently leak them, but we'd leak them for the write timeout (10s).
* It's a waste of bandwidth. * It causes us to think the connection is dead because the other side is too busy sending us _other_ data to respond to the ping. fixes #15
// peer is busy sending us stuff, the pong might get stuck | ||
// behind a bunch of data. | ||
if s.keepaliveTimer != nil { | ||
s.keepaliveTimer.Reset(s.config.KeepAliveInterval) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the bugfix.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't you need to check if the timer has already been read as described in https://golang.org/pkg/time/#Timer.Reset?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this one gets me every time too -- the API for resetting timers is really poor.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not in this case. Reset actually stops it internally.
You have to stop it first and drain the channel if you want to make sure that the previous timer doesn't fire after you reset it but before new timeout elapses. However:
- We don't really care in this case.
- This isn't a normal timer, it's an AfterFunc and doesn't have a channel to drain. There's no way to reliably stop an AfterFunc because the function is called asynchronously. Note: trying to drain a channel of a timer created by
AfterFunc
will just block forever.
fixes #15