Discover
Download
Find Content
Optimize
Help & Support
Forum
News
Your donations fuel development!
Crypto:   Bitcoin  BitcoinCash  Verge  ZCash
Litecoin   Ripple   Monero   Dogecoin
Credit Card: PayPal Secure Payments
Login, or feel free to register!
The time is 2019/01/18 03:35:54 AM
Your IP is 54.226.64.30

Off Topic

Report problems with the forum itself, or any thing else not specific to Tixati
<<  Back to Forum
[Tech Support] Please share how tixati does NAT traversal
by devxpy on 2018/08/17 10:16:52 AM
I've been trying to do p2p communication, between 2 clients behind a NAT for around a year now...

I have tried multiple solutions to this problem, but the only technology that successfully seems solve this is bittorrent.

Personally tried to implement something (in python) using this paper - http://www.brynosaurus.com/pub/net/p2pnat/.

Specifically the "3.4 Peers Behind Different NATs" section. However, even after multiple attempts, I can't get the same level of stability as bittorent (Mostly doesn't work at all).

I also implemented NAT-PMP and NAT-PCP in python. However, the 3 networks I tested it on didn't support these technologies.

Also tried a uPnP client (miniupnpc). Unfortunately, my NAT router doesn't support that either.

So as a fellow developer, I request you share your technique of achieving this feat.

Thanks,
Dev Aggarwal.

Github - https://github.com/devxpy

by Guest on 2018/08/19 05:25:10 PM
Torrent clients usually support an extension that facilitates relaying "hole-punch" messages for other peers. Combined with peer-exchange, which allows you to know the connections of your connections, your client can hole-punch with other clients that share a common connection to serve as a relay.

Peer A is already connected to Peer B

Peer B is already connected to Peer C

When Peer A wants to connect to Peer C, it sends a message to Peer B, who relays it to Peer C, with Peer A's IP and Port

While Peer A is sending UDP connection initiation packets to Peer C, Peer C is also sending UDP connection initiation packets to Peer A. The NAT on both sides will then have a mapping for the replies that usually stays active as long as there are packets exchanged at least once every 30+ seconds.

During this connection setup, a few initial packets may be lost depending on the timing of things, but retries are sent and eventually both ends have an opening in their firewalls for each other.

Here's a link that may help with these concepts (I don't have time to really explain in full detail):

https://en.wikipedia.org/wiki/UDP_hole_punching

The actual extension message that torrent clients use is called "ut_holepunch", but that's just the method to relay the hole-punch setup message. You could try a web search for that extension for details.

BTW this only works for UDP, it is not usually worth it to try hole-punching TCP because it is much more complicated and rarely works.

by Guest on 2018/09/30 04:25:58 AM
Thanks for the info,

Can you please clear up this one doubt for me?


If we have `S` (the globally accessible IP server) and `N1` & `N2` (Two clients behind a NAT) -


1. `N1` & `N2` contact `S`, with their local addresses
(Say `udp://<LA1>:<LP1>` and `udp://<LA2>:<LP2>`).

2. Then `S` reports the global address of the NATs it sees
(Say `udp://<GA1>:<GP1>` and `udp://<GA2>:<GP2>`).

---

My doubt is the following :

Do N1 and N2 try to send packets to `udp://<GAx>:<GPx>` or `udp://<GAx>:<LPx>`.

Which means, should they try to send packets at the globally visible port number or their local port number?