-
Notifications
You must be signed in to change notification settings - Fork 494
fix: prevent duplicate connections to multiaddr #2734
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
base: main
Are you sure you want to change the base?
Conversation
After opening a new connection, check if there is an existing connection to the same peer. If the existing connection is not limited or the new connection is also limit, return the existing connection. This will prevent multiple connections to the same peer in cases where the multiaddr being dialed does not contain a peer id.
Checks that the dialer is returning existing connections to the same peer when given a multiaddr without a peer id.
I've added two tests to check that the existing or new connection is returned appropriately. |
93ec16c
to
71ea20e
Compare
In practice this shouldn't happen since the only limited connections we have are circuit relay connections, and we can't dial one without the target peer being in the multiaddr (as the relay needs to know which onward peer we are trying to dial), so the connection should already have been de-duplicated based on the target peer id in the multiaddr and a second relayed connection not opened. |
Title
fix: prevent duplicate connections to multiaddr
Description
After opening a new connection, check if there is an existing connection
to the same peer. If the existing connection is not limited or the new
connection is also limit, return the existing connection.
This will prevent multiple connections to the same peer in cases where
the multiaddr being dialed does not contain a peer id.
Notes & open questions
Closes #2714
There is a small change from what was requested in the issue. An existing limited connection will be returned if the new connection is also limited.
Should
conn.close()
be awaited before returning the existing connection?Where should a test for this be added?
Change checklist