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@cubik.org
http://lists.cubik.org/mailman/listinfo/enet-discuss
_______________________________________________
ENet-discuss mailing list
ENet-discuss@cubik.org
http://lists.cubik.org/mailman/listinfo/enet-discuss
