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

fix: don't keepalive when the connection is busy #16

Merged
merged 3 commits into from
Mar 13, 2020

Conversation

Stebalien
Copy link
Member

  • 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

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the bugfix.

Copy link
Contributor

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?

Copy link
Contributor

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.

Copy link
Member Author

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:

  1. We don't really care in this case.
  2. 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.

@Stebalien Stebalien merged commit 51522d4 into master Mar 13, 2020
@Stebalien Stebalien deleted the fix/defer-keepalive branch March 13, 2020 18:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Connections cut under heavy load
4 participants