There's more on it here: http://alumnus.caltech.edu/~dank/peer-nat.html
On Mon, May 2, 2011 at 10:27 PM, Josh Klint <[email protected]> wrote: > 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 >
_______________________________________________ ENet-discuss mailing list [email protected] http://lists.cubik.org/mailman/listinfo/enet-discuss
