-
-
Notifications
You must be signed in to change notification settings - Fork 396
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
#2008: Make max_idle_timeout negotiation commutative. #2009
Conversation
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.
These changes make sense to me, thanks!
# This is the 1st commit message: quinn-rs#2008: Make max_idle_timeout negotiation commutative. # This is the commit message quinn-rs#2: quinn-rs#2008: Store negotiated idle_timeout as Duration. # This is the commit message quinn-rs#3: quinn-rs#2009: Address code review feedback.
c5882f4
to
11e6de0
Compare
Ensure that both endpoints can agree on the same idle_timeout value, regardless of the announced max_idle_timeout parameters. This fix addresses a corner case where a locally configured idle_timeout of 0 was used as the negotiated value instead of the non-zero max_idle_timeout provided by the remote side.
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.
Thanks!
The original intent here was that users pass None
to TransportConfig::max_idle_timeout
, rather than Some(0)
, if no maximum timeout is desired. I wonder if we should revisit that interface to make this less of a footgun? For example, we could make IdleTimeout
require a nonzero number of milliseconds, or round up to 1, or something to that effect.
Thinking about how we would explain that interface in documentation makes me feel that it would make things more complex rather than easier? We could potentially add some explicit documentation about |
This is a strict non-breaking improvement, anyway. |
Fixes #2008.