Skip to content
This repository was archived by the owner on Oct 29, 2024. It is now read-only.

Conversation

@dennis-tra
Copy link

Having an idle connection timeout value of 0 makes it hard to open a stream to the rust bootstrappers. On the Go side, we're dialing the peer and then doing the identify exchange. Only after this exchange has completed, we can open a stream. However, in this short period of time rust-libp2p will prune the connection because it's idle.

One fix on our side is to only dial the bootstrapper and then do our crawling/fetching/etc. in parallel to the identify exchange. However, this is only a bandaid solution. It would be better to allow connecting peers a little bit of time to prove their usefulness.

This is also discussed in rust-libp2p here: libp2p/rust-libp2p#4912

Theoretically, the issue could be amplified in situations where the rust peer is overloaded and the state machine can't keep up with events. The connection may be considered idle and get pruned although there is an "open stream"-event waiting to be consumed.

Moreover, as far as I can tell, the connection_idle_timeout configuration parameter isn't even used anywhere.

This PR is should just be a discussion starter. If this gets merged, I guess you would want to apply the changes to your other components (like light clients) as well.

cc @vbhattaccmu

for context my discuss.libp2p post: https://discuss.libp2p.io/t/rust-go-interop-idle-connection-timeout-race-condition/2470/3

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant