n2n hold punching

[russ1217]

lately I noticed that there is new publications about using two servers instead of one to apply new hold punching method in make sure NAT4 can have peer-to-peer direct link. https://www.researchgate.net/publication/228411948_A_New_Method_for_Symmetric_NAT_Traversal_in_UDP_and_TCP I wonder if the latest 3.0 supernode federation has already applied such technology? Or, is there a plan of doing so?

[Logan007]

Hello!

I wonder if the latest 3.0 supernode federation has already applied such technology?

No, the edges select one supernode and perform hole punching with the chosen one only so far.

If I remember correctly, this paper came up in some earlier discussion but no-one showed up to explain or even implement.

I still have not understood every detail of that paper, and, to be honest, have not taken the time to go in-depth there as well, so far – but it seems that n2n already offers some of it. In src/edge_utils.c:689 we have a section which performs some simple port predicion (not on Windows, and if TTL CLI parameter above 1 supplied), also see #115 for more details.

One more approach to perform some (random) and more aggressive port "checking" was tried in #839 but never finished.

[russ1217]

Hi,

Thanks for your time to reply. Glad to know that n2n developers are already aware of this article. I read it casually and found that it seems that using two servers may increase the p2p rate. However, if it is implemented, I assume that n2n protocal will need to have a considerable change. Not sure if it is worth doing. 

My experience now is, with your port prediction, p2p success ratae can be greatly improved. However, if both ends are NAT4 (symmetric), direct link is still pretty hard. That case may need the method of this article, however not sure if it is economic to do so.

 Regards,

Russ Rao

在 2022-05-25星期三的 01:40 -0700，Logan oos Even写道：

Hello!

I wonder if the latest 3.0 supernode federation has already applied such technology? No, the edges select one supernode and perform hole punching with the chosen one only so far. If I remember correctly, this paper came up in some earlier discussion but no-one showed up to explain or even implement. I still have not understood every detail of that paper, and, to be honest, have not taken the time to go in-depth there as well, so far – but it seems that n2n already offers some of it. In src/edge_utils.c:689 we have a section which performs some simple port predicion (not on Windows, and if TTL CLI parameter above 1 supplied), also see #115 for more details. One more approach to perform some (random) and more aggressive port "checking" was tried in #839 but never finished. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>