So what you're saying is: Client - player who wants to play game Server - player who wants to host game Participant #3 (for lack of a better term) - program running on a dedicated server
Client and Server both creates client hosts that connect to Participant #3, which is running at a known IP address, on a known port. Participant #3 gets Server's IP address and port, and sends this information to Client. Client uses this information to immediately connect to Server, using the IP address and port provided by Participant #3. Is that correct? So really the only time you need this is when Server is behind a router. If Server was a player plugged straight into a modem, or Server was a dedicated server, this would not be necessary. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Lee Salzman Sent: Monday, May 02, 2011 1:30 PM To: Discussion of the ENet library Subject: Re: [ENet-discuss] NAT punch-through 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 _______________________________________________ ENet-discuss mailing list [email protected] http://lists.cubik.org/mailman/listinfo/enet-discuss
