Just create both hosts and open a normal ENet connection on both hosts to some third party server not behind a NAT. This server should then report the addresses to both of the hosts needing to take part in the connection. The hosts can then use these addresses to connect to eachother, but just make sure you connect immediately after, or the router may close down the port again. Once that's up, the normal ENet keepalive ping is probably good enough by itself to keep the connection open. This works because each ENet host maintains a single UDP socket for all its connections, so provided you are on an asymmetric NAT, once the initial connection to the third party opens the port, it should keep that port open provided you are servicing the connection regularly.
Note this will only work with asymmetric NATs - as in the router opens a port that works for any remote client to connect back to, so even if A is behind NAT, and connects to B, another peer C can connect to the address opened for A. Symmetric NAT is hell and only lets B connect back to A, not C, and there's basically no sane way to punch through those. Exactly what the third party is really depends on your application, and it not something that belongs in ENet proper. On 05/03/2011 01:34 AM, Chris Meub wrote:
I am by no means an expert on the subject, but I am using a really basic form of NAT punch-through with Enet at the moment with a hobby project. I have 2 clients, one at home behind a consumer router, and 1 at the office behind a firewall. Both connect to a central server, and begin transmitting packets to the server. The server collates the packets into simulation step packets, and sends those back to each client. This system works fine and I've had no issues with our firewall or any routers. Now I imagine if you wanted to get rid of the central server, that would be another story. You would probably have to still use a central server for matchmaking and then do some trickery to figure out which IP+port each peer needed to start sending packets to in order to bypass the firewall(s). But I imagine one could still do that with Enet. The only other thing I can think of would be some kind of brute force library that randomly tries ports until it finds one that can get through the firewall. Is that what RakNet provides? On Mon, May 2, 2011 at 1:32 PM, Josh Klint <[email protected] <mailto:[email protected]>> wrote: Hi, A search for enet and NAT punch-through yields a lot of questions about whether this is possible and discussion of how it might be done, but I have never found an actual instance of working code, or anyone who claims to have successfully implemented NAT punch-through with enet. I love the simplicity of enet, but without NAT punch-through support, I don't see how it is useful for networked software. I’ll have to (unfortunately) go with RakNet, which is huge, bloated, and comes with licensing hang-ups I have to pass on to my customers. Best Regards, Josh Klint CEO Leadwerks Software
_______________________________________________ ENet-discuss mailing list [email protected] http://lists.cubik.org/mailman/listinfo/enet-discuss
