Skip to content
This repository has been archived by the owner on May 26, 2022. It is now read-only.

don't compare peer IDs when hole punching #210

Merged
merged 1 commit into from Jul 7, 2021

Conversation

marten-seemann
Copy link
Collaborator

@mxinden pointed out that comparing peer IDs when hole punching is not necessary. We'll have logic in our DCUtR protocol anyway to assign the role of client and server (we'll need the same logic to coordinate the TCP sim open).

@vyzo
Copy link
Contributor

vyzo commented Jul 5, 2021

Sounds like a good idea, but we'll have to change the code in the hole punching pr in go-libp2p so that only one of the peers uses the option, predictably.

@marten-seemann
Copy link
Collaborator Author

I added a comment to that PR, so we don't forget. I suggest moving forward with this PR, and not blocking on that change.

@vyzo
Copy link
Contributor

vyzo commented Jul 5, 2021 via email

Copy link
Member

@mxinden mxinden left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mxinden pointed out that comparing peer IDs when hole punching is not necessary. We'll have logic in our DCUtR protocol anyway to assign the role of client and server (we'll need the same logic to coordinate the TCP sim open).

Approving the idea of assigning roles through the DCUtR protocol instead of by comparing peer IDs.

Copy link
Member

@Stebalien Stebalien left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Someday, maybe, we can expose a separate HolePunch (or ActiveListen) function instead....

@marten-seemann
Copy link
Collaborator Author

Someday, maybe, we can expose a separate HolePunch (or ActiveListen) function instead....

I wouldn't be opposed to that.

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.

None yet

4 participants