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

Improve experience with NAT'ed/Firewalled peers #614

Closed
5 of 9 tasks
hsanjuan opened this issue Dec 7, 2018 · 1 comment · Fixed by #932
Closed
5 of 9 tasks

Improve experience with NAT'ed/Firewalled peers #614

hsanjuan opened this issue Dec 7, 2018 · 1 comment · Fixed by #932
Assignees
Labels
exp/wizard Extensive knowledge (implications, ramifications) required P1 High: Likely tackled by core team if no one steps up status/in-progress In progress

Comments

@hsanjuan
Copy link
Collaborator

hsanjuan commented Dec 7, 2018

Basic information

  • Version information (mark as appropiate):
    • Master
    • Release candidate for next version
    • Latest stable version
    • An older version I should not be using
  • Type (mark as appropiate):
    • Bug
    • Feature request
    • Enhancement

Description

Since we enabled DHT discovery we stopped manually opening connections to every peer when joining (which was a mess). A downside is that a firewalled peer can only join by talking directly to the leader and in some cases, by manually opening connections to the rest of peers in the cluster.

We should:

  • Start testing QUIC and see if it improves NAT hole-punching
  • Study libp2p p2p-circuit (relay) which is now enabled by default but I don't know if something else
    is needed. In this case, it should enable any peer to reach firewalled peers through the peer it first contacted.

The scenario that should work is 2 peers online, reachable on the internet, and peers behind NAT or with incoming ports filtered should be able to join the cluster, and be reached by any other peer in it (even other firewalled peers on different networks).

@hsanjuan hsanjuan added help wanted Seeking public contribution on this issue status/ready Ready to be worked P1 High: Likely tackled by core team if no one steps up difficulty:moderate labels Dec 7, 2018
@hsanjuan hsanjuan added exp/wizard Extensive knowledge (implications, ramifications) required and removed difficulty:moderate labels Jul 23, 2019
@hsanjuan
Copy link
Collaborator Author

hsanjuan commented Sep 26, 2019

Actionables:

  • EnableRelay() and EnableAutoRelay(), make sure that nodes are relays and dialable through relays. Learn how these options work and how the relay protocol works. Learn how IPFS is doing it and do it similarly. At the end: introduce a configuration option to enable a cluster peer to become a relay for others (the use of relays should be enabled by default).
  • Enabling QUIC: make the necessary changes so that cluster peers can use QUIC. Figure out if something is missing from the libp2p stack so that it works with ed25519 keys. Learn whether the TLS 1.3 handshake needs to be, additionally, manually enabled for it to work.
  • Add QUIC listen address by default in backwards compatible matter by fixing Allow multiple libp2p addresses #914. Thus, nodes can listen on one or several addresses. The Strings type from go-ipfs-config can be used here (no need to copy paste).

@hsanjuan hsanjuan added status/in-progress In progress and removed help wanted Seeking public contribution on this issue status/ready Ready to be worked labels Sep 26, 2019
@hsanjuan hsanjuan mentioned this issue Nov 5, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
exp/wizard Extensive knowledge (implications, ramifications) required P1 High: Likely tackled by core team if no one steps up status/in-progress In progress
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants