-
Notifications
You must be signed in to change notification settings - Fork 43
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
feat: don't allow to open more than 256 unacknowledged streams #153
feat: don't allow to open more than 256 unacknowledged streams #153
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.
A lot less intrusive than I thought. Neat!
Also thanks for the simple tests testing a difficult scenario.
yamux/src/connection/stream.rs
Outdated
|
||
pub fn is_acknowledged(&self) -> bool { | ||
self.shared().acknowledged | ||
} |
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.
Why expose this to the user? For the test above only? If so, can we move the test instead?
pub fn is_acknowledged(&self) -> bool { | |
self.shared().acknowledged | |
} | |
pub(crate) fn is_acknowledged(&self) -> bool { | |
self.shared().acknowledged | |
} |
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.
I think in the context of rust-yamux
, this is useful information. Yes, it also allows us to keep the test next to all the others.
I am not too worried about this being in the public API because it is encapsulated within libp2p-yamux
anyway. A nice benefit is that our tests are written against a more stable interface instead of reaching into internal data structures.
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.
I think in the context of
rust-yamux
, this is useful information
In what scenario would a user use it?
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.
Until the point where the stream is not acknowledged, this is essentially equivalent to asking a QUIC connection whether it is 0RTT. Anything you write to a stream before it is acknowledged might be discarded by the remote.
Co-authored-by: Max Inden <mail@max-inden.de>
Co-authored-by: Max Inden <mail@max-inden.de>
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.
We seem to have a misunderstanding. I don't think inbound streams should be accounted in self.ack_backlog() >= MAX_ACK_BACKLOG
.
yamux/src/connection/stream.rs
Outdated
// technically, the frame hasn't been sent yet on the wire but from the perspective of this data structure, we've queued the frame for sending | ||
if frame.header().flags().contains(ACK) { | ||
self.set_acknowledged(); | ||
} |
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 confusing to me. Do I understand correctly that this sets an inbound stream to be acknowledged? Why would the local state machine care whether an inbound stream is acknowledged or not?
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.
We can omit this but it means that the flag is only used by outbound streams which IMO is even more confusing.
I guess I could rename it?
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.
Ah, I remember why I am doing it for both. I needed that for the test around timing, i.e. when a stream gets acknowledged.
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.
That is fine by me. Though could you please document it for future us?
This doesn't actually save any LoC.
This is still buggy for some reason. I am not sure if it has to do with the recently merged changes and the GC fix. Will put on hold for now. |
This test is covered by `prop_send_recv_multi`.
I've merged #164 into here and now this PR passes all tests 🥳 |
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.
yamux/src/connection/stream.rs
Outdated
|
||
pub fn is_acknowledged(&self) -> bool { | ||
self.shared().acknowledged | ||
} |
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.
I think in the context of
rust-yamux
, this is useful information
In what scenario would a user use it?
yamux/src/connection/stream.rs
Outdated
// technically, the frame hasn't been sent yet on the wire but from the perspective of this data structure, we've queued the frame for sending | ||
if frame.header().flags().contains(ACK) { | ||
self.set_acknowledged(); | ||
} |
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.
That is fine by me. Though could you please document it for future us?
Resolves #150.