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
Set a better default for idle_connection_timeout
#4912
Comments
A default of 10 seconds may be enough to accommodate majority of the protocols, but setting to 30 seconds may be the best balance in my opinion |
30 seconds seems like a lot to me. The main usecase that we talked about yesterday was to be able to initiate protocols with peers from outside the Anything longer feels too application-specific but I don't have any data to back that up. |
An alternative would be to entirely remove auto-closing and instead emit an event notifying the user that the connection is idle. Would that perhaps be useful? |
That actually doesnt sound like a bad idea. Kind of curious to see how that would play out long term. |
Typically, the problem with these kind of approaches is that by default, users will only handle the events that the care about and In this particular case though, that doesn't actually do any harm! (Until you run into connection limits for example). At that point however, you are probably familiar enough with To make the simple case of a timeout easier, we could re-emit this event every X seconds and include, how long the connection is already idle. Then users wouldn't need to keep any state outside of the Curious to hear what @mxinden thinks. |
I find it quite difficult to gauge what would be considered a bigger annoyance / "rust-libp2p"-ism:
From a library PoV, the latter is "better" because it gives the user more power over the policy on when to close connections. At the same time, not closing them at all might be a weird default? We could add |
I'm curious what amount of resources open connections use. Are they cheap or expensive? I would think that would influence the decision a bit? |
On @mxinden kademlia-exporter node, a single connection uses about 300kb. I'd expect an idle connection, even with more protocols enabled to not consume much more than that because the presence of buffered data would mean that the connection is not idle. Hence, all buffers should be empty on an idle connection, unless we have a memory leak somewhere. In addition to that, an open connection consumes a file descriptor (or equivalent depending on OS). |
couple of things might related to this |
To my knowledge, if the connected peers are subscribed to the same gossipsub topic on the node, their connection will be kept alive until they are no longer apart of the mesh (eg unsubscribed from the topic). Not sure if this is applicable for your use case though.
Just being curious, is this with just TCP or TCP + Quic setup? |
No, most of the nodes are not subscribed to any topic. Only 2% of the nodes subscribed to the same topic.
just TCP |
An active gossipsub stream will keep the connection alive even if the nodes aren't subscribed to the same topics. There isn't really much we can do about that. The best solution is to (as you are already doing), close those connections manually. |
As discussed yesterday in #4905.
Needs:
The text was updated successfully, but these errors were encountered: