There's more on it here: <a href="http://alumnus.caltech.edu/~dank/peer-nat.html">http://alumnus.caltech.edu/~dank/peer-nat.html</a><br><br><div class="gmail_quote">On Mon, May 2, 2011 at 10:27 PM, Josh Klint <span dir="ltr"><<a href="mailto:jklint@leadwerks.com">jklint@leadwerks.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">So what you're saying is:<br>
<br>
Client - player who wants to play game<br>
Server - player who wants to host game<br>
Participant #3 (for lack of a better term) - program running on a dedicated<br>
server<br>
<br>
Client and Server both creates client hosts that connect to Participant #3,<br>
which is running at a known IP address, on a known port.<br>
<br>
Participant #3 gets Server's IP address and port, and sends this information<br>
to Client.<br>
<br>
Client uses this information to immediately connect to Server, using the IP<br>
address and port provided by Participant #3.<br>
<br>
Is that correct?  So really the only time you need this is when Server is<br>
behind a router.  If Server was a player plugged straight into a modem, or<br>
Server was a dedicated server, this would not be necessary.<br>
<br>
<br>
-----Original Message-----<br>
From: <a href="mailto:enet-discuss-bounces@cubik.org">enet-discuss-bounces@cubik.org</a> [mailto:<a href="mailto:enet-discuss-bounces@cubik.org">enet-discuss-bounces@cubik.org</a>]<br>
On Behalf Of Lee Salzman<br>
Sent: Monday, May 02, 2011 1:30 PM<br>
To: Discussion of the ENet library<br>
Subject: Re: [ENet-discuss] NAT punch-through<br>
<div><div></div><div class="h5"><br>
Just create both hosts and open a normal ENet connection on both hosts to<br>
some third party server not behind a NAT. This server should then report the<br>
addresses to both of the hosts needing to take part in the connection. The<br>
hosts can then use these addresses to connect to eachother, but just make<br>
sure you connect immediately after, or the router may close down the port<br>
again. Once that's up, the normal ENet keepalive ping is probably good<br>
enough by itself to keep the connection open. This works because each ENet<br>
host maintains a single UDP socket for all its connections, so provided you<br>
are on an asymmetric NAT, once the initial connection to the third party<br>
opens the port, it should keep that port open provided you are servicing the<br>
connection regularly.<br>
<br>
<br>
Note this will only work with asymmetric NATs - as in the router opens a<br>
port that works for any remote client to connect back to, so even if A is<br>
behind NAT, and connects to B, another peer C can connect to the address<br>
opened for A. Symmetric NAT is hell and only lets B connect back to A, not<br>
C, and there's basically no sane way to punch through those.<br>
<br>
Exactly what the third party is really depends on your application, and it<br>
not something that belongs in ENet proper.<br>
<br>
On 05/03/2011 01:34 AM, Chris Meub wrote:<br>
> I am by no means an expert on the subject, but I am using a really basic<br>
form of NAT punch-through with Enet at the moment with a hobby project. I<br>
have 2 clients, one at home behind a consumer router, and 1 at the office<br>
behind a firewall. Both connect to a central server, and begin transmitting<br>
packets to the server. The server collates the packets into simulation step<br>
packets, and sends those back to each client. This system works fine and<br>
I've had no issues with our firewall or any routers.<br>
><br>
> Now I imagine if you wanted to get rid of the central server, that would<br>
be another story. You would probably have to still use a central server for<br>
matchmaking and then do some trickery to figure out which IP+port each peer<br>
needed to start sending packets to in order to bypass the firewall(s). But I<br>
imagine one could still do that with Enet.<br>
><br>
> The only other thing I can think of would be some kind of brute force<br>
library that randomly tries ports until it finds one that can get through<br>
the firewall. Is that what RakNet provides?<br>
><br>
> On Mon, May 2, 2011 at 1:32 PM, Josh Klint <<a href="mailto:jklint@leadwerks.com">jklint@leadwerks.com</a><br>
<mailto:<a href="mailto:jklint@leadwerks.com">jklint@leadwerks.com</a>>> wrote:<br>
><br>
>     Hi,<br>
><br>
>     A search for enet and NAT punch-through yields a lot of questions<br>
about whether this is possible and discussion of how it might be done, but I<br>
have never found an actual instance of working code, or anyone who claims to<br>
have successfully implemented NAT punch-through with enet.<br>
><br>
>     I love the simplicity of enet, but without NAT punch-through support,<br>
I don't see how it is useful for networked software.  I'll have to<br>
(unfortunately) go with RakNet, which is huge, bloated, and comes with<br>
licensing hang-ups I have to pass on to my customers.<br>
><br>
>     Best Regards,<br>
><br>
>     Josh Klint<br>
><br>
>     CEO<br>
><br>
>     Leadwerks Software<br>
><br>
><br>
<br>
_______________________________________________<br>
ENet-discuss mailing list<br>
<a href="mailto:ENet-discuss@cubik.org">ENet-discuss@cubik.org</a><br>
<a href="http://lists.cubik.org/mailman/listinfo/enet-discuss" target="_blank">http://lists.cubik.org/mailman/listinfo/enet-discuss</a><br>
<br>
_______________________________________________<br>
ENet-discuss mailing list<br>
<a href="mailto:ENet-discuss@cubik.org">ENet-discuss@cubik.org</a><br>
<a href="http://lists.cubik.org/mailman/listinfo/enet-discuss" target="_blank">http://lists.cubik.org/mailman/listinfo/enet-discuss</a><br>
</div></div></blockquote></div><br>