<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#ffffff">
    <a href="http://en.wikipedia.org/wiki/UDP_hole_punching">http://en.wikipedia.org/wiki/UDP_hole_punching</a><br>
    <br>
    And also, The miniupnpc lib DOES work on windows. I use it all the
    time (and iOS, Mac, Linux, etc)<br>
    <br>
    On 5/3/2011 8:37 AM, Chris Meub wrote:
    <blockquote
      cite="mid:BANLkTina+5ee4HhUghnUtcK9qV4oTAfGjQ@mail.gmail.com"
      type="cite">There's more on it here: <a moz-do-not-send="true"
        href="http://alumnus.caltech.edu/%7Edank/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 moz-do-not-send="true"
            href="mailto:jklint@leadwerks.com">jklint@leadwerks.com</a>></span>
        wrote:<br>
        <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
          0.8ex; border-left: 1px solid rgb(204, 204, 204);
          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 moz-do-not-send="true"
            href="mailto:enet-discuss-bounces@cubik.org">enet-discuss-bounces@cubik.org</a>
          [mailto:<a moz-do-not-send="true"
            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 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
                moz-do-not-send="true"
                href="mailto:jklint@leadwerks.com">jklint@leadwerks.com</a><br>
              <mailto:<a moz-do-not-send="true"
                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 moz-do-not-send="true"
                href="mailto:ENet-discuss@cubik.org">ENet-discuss@cubik.org</a><br>
              <a moz-do-not-send="true"
                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 moz-do-not-send="true"
                href="mailto:ENet-discuss@cubik.org">ENet-discuss@cubik.org</a><br>
              <a moz-do-not-send="true"
                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>
      <pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
ENet-discuss mailing list
<a class="moz-txt-link-abbreviated" href="mailto:ENet-discuss@cubik.org">ENet-discuss@cubik.org</a>
<a class="moz-txt-link-freetext" href="http://lists.cubik.org/mailman/listinfo/enet-discuss">http://lists.cubik.org/mailman/listinfo/enet-discuss</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>