[ENet-discuss] Enet and NAT hole punching

Martin Sherburn spacedude at konggame.co.uk
Wed Jan 7 02:44:15 PST 2009


I suggest you look at the STUN protocol, it's not bulletproof. In fact 
it's pretty much impossible to make a bulletproof NAT traversal system. 
But it's a good start. The protocol is defined in this document:
http://www.ietf.org/rfc/rfc3489.txt
overview at wikipedia: http://en.wikipedia.org/wiki/Stun. (Note that the 
wikipedia page claims that the protocal has been superseeded by a newer 
protocol however I can't find any implementations of the newer one so...)

There are several open-source implementations of the STUN protocol, have 
a look at the following (this is written in C or C++ can't remember which):
http://sourceforge.net/projects/stun/

If you are into python then you can check out this Python implementation:
http://code.google.com/p/boogu/

The advantage of using this protocol is that there a few free servers 
that you can use, so you can use them for testing if you don't have the 
resources to run your own. You could implement the protocol using ENet, 
and if I were to do it again that's probably the route I would take. I 
tried doing my own custom version but in order to test it you really 
need at least 3 computers on 3 different internet connections (1 server 
+ 2 clients). And then you'll just be testing a single configuration, 
there are so many different routers out there that you'll spend a 
considerable amount of time even just to test a fraction of them. So in 
the end I never got the chance to test it properly and didn't get a good 
idea of how well my implementation worked.

Martin.

M. Rijks wrote:
> Hi everyone,
>
> I'm happy to have found Enet as it provides the perfect mix of 
> advantages between UDP and
> TCP. I'm currently in planning stages of developing a client-server 
> multiplayer library
> on top of it. Now, in most smaller-scale multiplayer games one of the 
> clients is usually
> also the server. The problem with hosting the game these days however 
> are firewall/NAT
> routers - you need to fiddle with port forwarding to host a game. 
> Connecting usually
> isn't a problem as outgoing connections usually get a port forwarded 
> automatically.
>
> A popular technique to circumvent these is NAT hole punching. The 
> server first connects
> to a publically available session server. This outgoing message makes 
> a firewall/NAT
> router open up an external port for the game server. Other clients 
> connect to the session
> server, which then passes the external IP and port of the game server, 
> so that the
> clients can then connect directly to the game server. It is a nice 
> technique that usually
> solves much of the hosting issues for people behind a NAT router, as 
> they don't even need
> to know their public IP and port. There is little stress on the 
> session server as it only
> acts as a helper.
>
> Let's assume that I will create my own public session server, 
> preferably using Enet as
> well (I'd like to keep track of a number of session statistics that 
> might be of interest
> to clients before joining). How would I go about setting this up? 
> Naturally, it's no
> problem for a client to have two outgoing connections (one to the 
> session server and one
> to the game server) but for the game server it's different - as far as 
> I can see you're
> either connecting as a client or waiting for connections as a server, 
> but I need to do
> both - if I set up two hosts it's going to use more than one port, 
> making the connection
> fail.
>
>
> Any suggestions welcome, thanks in advance,
>
> - Martin
>
> _______________________________________________
> ENet-discuss mailing list
> ENet-discuss at cubik.org
> http://lists.cubik.org/mailman/listinfo/enet-discuss



More information about the ENet-discuss mailing list