UDP Hole Punching / NAT Traversal

[Josh]

Details

Right now in 0 A.D. we use a primitive UPnP system to implement NAT traversal, but this system is unreliable. We would like to see a better method using UDP Hole Punching instead. The solution would involve interacting with the lobby server to get traversal information. The recommended implementation would use ​STUN with ​ICE. It may be possible to (ab)use ​XEP-0176: Jingle ICE-UDP Transport Method for the desired result. Ejabberd has a built-in STUN server (​Manual Entry). Both Ejabberd and Gloox support XEP-0176.

Expected Result

Enabling 0 A.D. clients to connect to a host behind any type of NAT.

Required Prerequisites

Fluency in C++ and understanding of NAT traversal. JavaScript knowledge would also be recommended. (Ability to learn/familiarity with erlang would also be required when dealing with the lobby server)

Helpful Links

​Incomplete/failed try at implementation

[JoshuaJB]

In 14332:

UPnP-based automatic port-forwarding using miniupnpc. Breaks windows build at the moment. Refs #2305

[Josh]

Because we now have UPnP-based automatic port forwarding (which serves nearly the same purpose), I'm dropping this ticket's priority.

[ben]

In 14352:

Fixes Windows build.
Fixes UPnP error handling to be more correct and conventional, refs #2305

[Josh]

I'm not really working on this anymore as I have not been able to fully understand what implementing this would require.

[historic_bruno]

Backlogging this due to lack of activity.

[Josh]

Added a few bits of information to the description from my recent research.

[fcxSanya]

It seems gloox has only data structures representing Jingle transport, but doesn't have any ICE logic (candidates gathering, exchange; connectivity checks; keeping connection alive etc.). ​libnice on the contrary is providing ICE logic, but as far as I understand it doesn't have signaling. I'm planning to write a proof-of-concept test application with gloox and libnice (essentially it requires only to combine sample apps for both libraries; also googling "gloox libnice" returns at least one application with available source which uses this combination of libraries (​https://github.com/yokto/xicecat)).

[fcxSanya]

Update for my previous comment:

I'm planning to write a proof-of-concept test application with gloox and libnice

I uploaded it here: ​https://github.com/AlexanderOlkhovskiy/gloox-libnice-test It basically works (I tested it only locally so far though), but requires some fixing, cleanup and refactoring.

[fcxSanya]

As I reported on the staff forums at the end of April, recent few months I was even less active in 0 A.D. development than usually due to personal life events. Part of the message is related to this ticket:

At winter/start of spring (when I had a bit more free time) I've written a test gloox/libnice application (linked in my last comment in the ticket) and I stopped on libnice/enet integration: in 0 A.D. we are using one enet host on host and enet clients for each player (including the host one). libnice seems to be intended to one-to-one interaction, so for each client we need to have a separate agent (or at least a separate stream) on host (at least that's the best way I was able to find and the one I implemented in the aforementioned test application), so the only way to integrate libnice I saw was to rewrite the network code sending data via libnice itself (what's probably its intended way of usage, but isn't good in our case) or maybe I needed more time to research.

Also earlier Georg suggested on IRC to look at STK implementation of NAT traversal which is done via STUN (which initially (in RFC 3489) was intended as a complete solution, but was reconsidered to be used only as part of higher-level protocols (in particular ICE) later (see RFC 5389)) in which case as far as I understand we are doing a STUN request from the intended host endpoint (generating the inside/outside endpoint mapping on the router and learning the outside one's address/port) and then start a enet host on it (sharing the router's outside endpoint with clients). I looked at the STK code (the STUN request itself is here: ​https://github.com/supertuxkart/stk-code/blob/master/src/network/protocols/get_public_address.cpp) and had some things to clarify, but then I didn't have enough free time to proceed with it.

I hope to proceed with these things once I will have a bit more free time (unless someone will be too tired of waiting and would finish the NAT traversal himself).

Since then I've written another test application consisting of STUN-related code extracted from STK: ​https://github.com/AlexanderOlkhovskiy/stk-stun-test It's less sophisticated than ICE-based solution, but it should be much easier to integrate it into 0 A.D.