Skip to content
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

NAT traversal: Swarm should allow creating a new connection between peers even if one already exists #1014

Closed
aarshkshah1992 opened this issue Nov 4, 2020 · 3 comments
Assignees

Comments

@aarshkshah1992
Copy link
Contributor

aarshkshah1992 commented Nov 4, 2020

libp2p Swarm currently does NOT allow two peers to create a new connection between them if one already exists.
This makes it difficult to hole punch via Relays and allow peers to choose the direct hole-punched connections over the existing Relay connection once we have the connection upgrade protocol in place.

@aarshkshah1992 aarshkshah1992 self-assigned this Nov 4, 2020
@aarshkshah1992 aarshkshah1992 changed the title Swarm should allow creating a new connection between peers even if one already exists NAT traversal: Swarm should allow creating a new connection between peers even if one already exists Nov 5, 2020
@aarshkshah1992
Copy link
Contributor Author

@Stebalien

Would you have suggestions/design notes for this ? I believe you have given this problem a thought before.

@Stebalien
Copy link
Member

I'm not sure at what level this should live. We could:

  • Have a dial option to force dial a specific set of transports/addresses.
  • Let the swarm itself decide if/when to "upgrade".

I'm wary of adding too much logic to the swarm, so I'd prefer the first option if we can make it work. I'm thinking something like:

  • Auto -- the default, just make sure there is a connection.
  • Direct -- try to create a direct connection, even if we have a connection.
  • OneOf(addressess...) try to form a connection to a specific target address.

To actually implement this, we'd likely need to restructure our dialing a bit. Currently, we coalesce all dials to a peer so there's no way to add in dial constraints after the fact when we have multiple concurrent dials. That'll need to change.

The simplest approach is probably to launch some kind of per-peer "dial" process that takes new dial requests and notifies these dial requests when their conditions have been satisfied.

@aarshkshah1992
Copy link
Contributor Author

This is now being tracked as part of #1039.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants