-
Notifications
You must be signed in to change notification settings - Fork 44
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: allow configuring stream limits #293
feat: allow configuring stream limits #293
Conversation
The registrar defaults to only allowing 1x inbound and 1x outbound stream per protocol so allow configuring more than that. I've plucked some defaults out of the air, these will need tuning to make sure they're not too restrictive or permissive.
Isn't the max incoming/outgoing streams per-connection? So you'd only need 1 in both direction? |
probably need to change the comments here: https://github.com/libp2p/js-libp2p-interfaces/blob/master/packages/interface-registrar/src/index.ts#L15 I've been so confused by the errors I'm seeing running lodestar. Definitely related to this. |
I think the incoming and outgoing limits should be the same no? We're doing some funky thing where we open two streams (one inbound, one outbound) per peer, and we read on one and write to the other. I can't find anything in the spec that suggests that this is necessary though... |
Yes, in this case one stream should suffice.
I'm not sure - my thinking was you wouldn't want a remote peer to connect to you then open a ton of streams and potentially fill up the incoming message buffer for each one, but you might want to open a ton of streams to a remote peer which is why I set it to be asymmetric.
They are per-connection limits, yes but an application might have some weird requirement that needs multiple simultaneous streams? I was definitely seeing IPFS test failures around IPNS over pubsub that were failing until I exposed the stream limits locally and upped the values.
If they are confusing people then yes, most likely. |
I think these defaults are too permissive. Gossipsub is a little different than many other protocols in that streams between peers are long-lived, and you only really need a single one. I'm not even sure what it means to have multiple gossipsub inbound or outbound streams for a single peer. (would published messages be pushed out to all streams? only the most recent?) Current behavior is we only currently 'track' two steams per peer (one inbound, one outbound). |
Here's a reference to why we're using unidirectional streams |
Co-authored-by: Cayman <caymannava@gmail.com>
libp2p/js-libp2p#1301 increases the default stream limits so we can go with these for now, we can always tune further at a later date. Talking to some of the libp2p folk, single, full-duplex or long-lived half-duplex gossipsub streams remove a bit of flexibility around things like low-power devices which may not be able to hold a connection open forever and may just want to periodically connect to send a message so I guess we should handle multiple incoming streams, also ones that only exist for the duration of one message, etc. |
Codecov Report
@@ Coverage Diff @@
## master #293 +/- ##
==========================================
+ Coverage 80.47% 81.53% +1.06%
==========================================
Files 42 43 +1
Lines 9104 9501 +397
Branches 826 918 +92
==========================================
+ Hits 7326 7747 +421
+ Misses 1778 1754 -24
Continue to review full report at Codecov.
|
The registrar defaults to only allowing 1x inbound and 1x outbound stream per protocol so allow configuring more than that.
I've plucked some defaults out of the air, these will need tuning to make sure they're not too restrictive or permissive.