-
Notifications
You must be signed in to change notification settings - Fork 446
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 #104
Comments
One more resource: - https://nice.freedesktop.org/wiki/ |
So there aren't any NAT Traversal techniques in js-libp2p? Not even Nat Port mapping? |
Work on this is planned already, and will begin very soon. |
Can't ipfs's NAT traversal just be reimplemented here? Why is it being worked on separately? |
Quick update and outline of what is currently being worked on:
|
I've added an issue describing the NAT flow here - #200 |
Hi all. What's the current state of affairs here? Any way for additional individuals to help out? |
We are planning on picking this back up this quarter, it's just lower on the priority list at the moment. The next steps for moving this forward are to finalize the specs, libp2p/specs#64, and work on getting the initial work of the nat manager finished, libp2p/js-libp2p-nat-mngr#1. The spec will be the big blocker to get resolved, so that nat manager can get moving again. There are a lot of considerations that need to get figured out, so any additional help/support there would be great! |
Hi! Is this on the table for Q2? It would be really nice to have for ipfs-deploy. |
Yes. This is on my list for the quarter and I am hoping to tackle this as well as #202 to help node addressing. |
Somebody said NAT traversal using libp2p-webrtc-star works. I have tried wrtc + libp2p-webrtc-star, but it's not working.
can somebody give an example or some docs? |
@suutaku what does your network setup look like in terms of libp2p nodes? Are you connecting both nodes to the same signaling server? The chat example at https://github.com/libp2p/js-libp2p-examples/tree/master/chat provides a setup that includes a node client, a node bootstrap node (with signaling server), and a browser client. I have not had the chance to test that across networks yet though. I am out next week but will be continuing work on the AutoNAT protocol in js when I am back. |
Welcome to back! we need you @jacobheun |
@suutaku are they both connected to a signaling server? You'll need to add listening addresses to both nodes for the signaling server, until we get a decentralized signaling protocol in place. This is adding a local address, |
@jacobheun thank you! I tried as you said. it's worked but not well. I mean I start a signaling server only sometime it worked. most time they can not find each other. |
by check log info. I found: 1. peer discovery was OK.peer can be discovered. 2. dial was failed.error info:
and listening on:
Update@jacobheun have did some test and research. I found NAT traversal is a big problem in China. by my case. internet works like:
maybe is difficult to punch a hole?
and also not working........ Update aginby launch a relay node with public ip, problem solved. |
@suutaku hole punching definitely is not 100%. WebRTC has our only method of doing this in JS right now. There are other NAT traversal techniques we're working on adding, but circuit relay is the best interim solution, assuming you have a dialable relay that both nodes are connected to. I am going to post some notes today on #385, which is likely going to require some more improvements to how circuits and webrtc signaling are done to help with this. For the relay config I'm adding some comments below to try and help clarify. Note, your relay node must be dialable, and both your other nodes must be connected to it at the moment. I'm looking to improve this with the work for #385. relay: {
enabled: true, // This line means your node is dialable over a Relay, but doesn't make it a relay itself
hop: {
enabled: true, // `true` means your node is a relay. So if two nodes are connected to it, it should relay their dials to one another
active: true // `true` means your node will attempt to actively dial the requested peer. This is likely not going to work in your situation, since your nodes aren't dialable.
}
} |
closing in favor of #1461 |
Bumps [aegir](https://github.com/ipfs/aegir) from 21.10.2 to 22.0.0. - [Release notes](https://github.com/ipfs/aegir/releases) - [Changelog](https://github.com/ipfs/aegir/blob/master/CHANGELOG.md) - [Commits](ipfs/aegir@v21.10.2...v22.0.0) Signed-off-by: dependabot-preview[bot] <[email protected]> Co-authored-by: dependabot-preview[bot] <27856297+dependabot-preview[bot]@users.noreply.github.com>
Currently, the only mechanism to pierce through NATs in js-libp2p is the WebRTC transport. NAT Traversal is a feature that is hard to get 100% complete as there will be always more NAT implementations that will not work with the strategies we have in place. Ultimately the last resort is Relay (Circuit or Packet Switched).
There is plenty of work available for NAT Traversal, WebRTC is kind of a canon to solve this problem, but not every peer will have WebRTC neither we can trust WebRTC 100% of the times.
Here is a list of good resources to get started:
The next milestone for Relay is to support UPnP for TCP ports, the same way go-ipfs does.
The text was updated successfully, but these errors were encountered: