[ENet-discuss] NAT punch-through

Tue May 3 02:20:20 PDT 2011

http://en.wikipedia.org/wiki/UDP_hole_punching

And also, The miniupnpc lib DOES work on windows. I use it all the time 
(and iOS, Mac, Linux, etc)

On 5/3/2011 8:37 AM, Chris Meub wrote:
> There's more on it here: 
> http://alumnus.caltech.edu/~dank/peer-nat.html 
> <http://alumnus.caltech.edu/%7Edank/peer-nat.html>
>
> On Mon, May 2, 2011 at 10:27 PM, Josh Klint <jklint at leadwerks.com 
> <mailto:jklint at leadwerks.com>> 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: enet-discuss-bounces at cubik.org
>     <mailto:enet-discuss-bounces at cubik.org>
>     [mailto:enet-discuss-bounces at cubik.org
>     <mailto:enet-discuss-bounces at cubik.org>]
>     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 <jklint at leadwerks.com
>     <mailto:jklint at leadwerks.com>
>     <mailto:jklint at leadwerks.com <mailto:jklint at leadwerks.com>>> 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
>     ENet-discuss at cubik.org <mailto:ENet-discuss at cubik.org>
>     http://lists.cubik.org/mailman/listinfo/enet-discuss
>
>     _______________________________________________
>     ENet-discuss mailing list
>     ENet-discuss at cubik.org <mailto:ENet-discuss at cubik.org>
>     http://lists.cubik.org/mailman/listinfo/enet-discuss
>
>
>
> _______________________________________________
> ENet-discuss mailing list
> ENet-discuss at cubik.org
> http://lists.cubik.org/mailman/listinfo/enet-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cubik.org/pipermail/enet-discuss/attachments/20110503/16c4d3d3/attachment.html>