Open wilfreddenton opened 7 years ago
I really hope the whole "NAT traversal" feature is not mentioned in this repo. I should have removed all mention of it a long time ago. If any occurrence of the word "NAT traversal" is still present in this repo, I will remove all of it.
UDP hole punching is how NAT traversal works with this library. But beyond that, when it comes to NAT traversal, UDP hole punching does not generally work. It will work with full-cone and I think address-restricted-cone, but beyond that, UDP hole punching is either really difficult (read, impractical), or impossible.
Thanks for the response.
You mention NAT traversal on the npm page.
No really; that above code will actually work, even if all hosts were sitting behind a NAT. Give it a try. For the heck of it, give rudp a try with a file sharing example.
From my understanding. UDP hole punching works on the majority of routers. I read this in this paper; see section 6.2. This paper also says that a rendezvous server is required for hole punching to work. You say your module uses hole punching but I don't see where I point it to a rendezvous server. Am I missing something?
This paper also says that a rendezvous server is required for hole punching to work. You say your module uses hole punching but I don't see where I point it to a rendezvous server. Am I missing something?
Yes, a rendezvous server is very helpful (if not, it's a requirement). You send a packet to the server, the server now has access to an IP address and port number. When another host asks for the address:port of the host that they want to talk to, the server will respond with said address:port, and will also record the host's address:port.
Then each client may go ahead and ping each other at the address and port that they got.
And the use of a rendezvous is not implemented in this library.
Ok so what you're saying basically is that if I wanted to use your library to connect two UDP clients behind NAT routers I would need to write/host my own rendezvous server as well as implement the hole punching algorithm on top of the library?
Yes.
Ok. Thank you for taking the time to discuss with this me. I'm trying to create a p2p chat app to learn more about p2p networking and I've slowly been putting the pieces together in my mind. This has been very helpful.
If you look at my example code, you will notice that the rudp.Client
constructor expects a dgram
socket as its first parameter.
I did this specifically so that this library may be able to piggy-back off of another NAT-traversal handshake library. After the handshake, it may continue communicating using the reliable UDP protocol.
Does this use some form of UDP hole punching? If so, then wouldn't this require a separately hosted rendezvous server? If this isn't the method used could you give a high level overview of what is happening? Thanks.