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

core/src/connection: Bound task event buffer during conn establishment #1501

Closed
wants to merge 4 commits into from

Conversation

mxinden
Copy link
Member

@mxinden mxinden commented Mar 19, 2020

This commit adds a size limit to the event buffer that is filled during
connection establishment and forwarded in bulk to the handler once the
connection is established.

When the size limit is reached an EventBufferLimitReached error is
triggered and send to the manager which will in turn drop its connection
to the task signaling it to shutdown.

The above buffer is already bound by the connection establishment
timeout. This commit adds an additional size bound to the buffer.

Fixes #1465.

Introduce unit test ensuring that the event buffer of a `Task` has a
limit and once exceeded that the `Task` sends an error back to the
manager and eventually fails.
This commit adds a size limit to the event buffer that is filled during
connection establishment and forwarded in bulk to the handler once the
connection is established.

When the size limit is reached an `EventBufferLimitReached` error is
triggered and send to the manager which will in turn drop its connection
to the task signaling it to shutdown.

The above buffer is already bound by the connection establishment
timeout. This commit adds an additional size bound to the buffer.
@@ -35,6 +35,8 @@ use futures::{prelude::*, channel::mpsc, stream};
use std::{pin::Pin, task::Context, task::Poll};
use super::ConnectResult;

const MAX_EVENT_BUFFERING: usize = 1000;
Copy link
Member Author

Choose a reason for hiding this comment

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

What would be a good limit? 1_000 might be a bit conservative.

@romanb
Copy link
Contributor

romanb commented Mar 20, 2020

I am wondering if it is actually still necessary to buffer these events in the background task at all, since the "take over" commands sent to pending connections in the context of the single-connection-per-peer constraint have been removed. The API poll_ready_notify_handler and notify_handler is now only exposed on an EstablishedEntry by the manager module. The only other code that sends events seems to be in poll_broadcast, which could (and maybe even should?) be changed to skip over pending connections. Just thinking out loud here as it would naturally be preferable to further simplify things.

@tomaka
Copy link
Member

tomaka commented Mar 24, 2020

I agree with @romanb. Being able to send events to connections that haven't been established yet was probably a mistake. poll_broadcast as well has not proven to be useful and could be removed as well.

@mxinden
Copy link
Member Author

mxinden commented Mar 24, 2020

Thanks for the feedback @romanb @tomaka.

To summarize we have two alternative approaches both relieving us off the need to buffer events in the first place.

  1. Have Manager::poll_broadcast skip TaskState::Pending tasks.

  2. Remove Manager::poll_broadcast.

In both cases one would still signal a Task to stop by dropping the TaskInfo::sender mspc::Sender, correct?

Do you have preferences on (1) or (2)?

@tomaka
Copy link
Member

tomaka commented Mar 24, 2020

In both cases one would still signal a Task to stop by dropping the TaskInfo::sender mspc::Sender, correct?

Yes.

Do you have preferences on (1) or (2)?

I'd just go with 2.

@romanb
Copy link
Contributor

romanb commented Mar 24, 2020

If poll_broadcast is not needed it is certainly preferable to remove it, especially since it already necessarily changed semantics with #1440.

In both cases one would still signal a Task to stop by dropping the TaskInfo::sender mspc::Sender, correct?

I'm not sure what you mean by that w.r.t. this PR? Do you mean what a Task should do if it receives an event for the connection handler while it is still pending? I suppose it would just panic, referring to the requirement that the Manager must not permit sending such events in that state.

@mxinden
Copy link
Member Author

mxinden commented Mar 30, 2020

Replaced by #1527. Thanks for the input!

@mxinden mxinden closed this Mar 30, 2020
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.

Potential unbounded buffer growth in background task of pending connection.
3 participants