title: TCP Hole Punching
body: <p>I'm trying to implement TCP hole punching with windows socket using mingw toolchain. I think the process is right but the <em>hole</em> doesn't seems to take. I used <a href="http://www.bford.info/pub/net/p2pnat/index.html" rel="noreferrer">this</a> as reference.</p>
  
  <ol>
  <li><strong>A</strong> and <strong>B</strong> connect to the server <strong>S</strong></li>
  <li><strong>S</strong> sends to <strong>A</strong>, <strong>B</strong>'s router IP + the port it used to connect to <strong>S</strong></li>
  <li><strong>S</strong> does the same for <strong>B</strong></li>
  <li><strong>A</strong> start 2 threads:
  
  <ul>
  <li>One thread tries connecting to <strong>B</strong>'s router with the info sent by <strong>S</strong></li>
  <li>The other thread is waiting for an incoming connection on the same port used to connect to its router when it connected to <strong>S</strong></li>
  </ul></li>
  <li><strong>B</strong> does the same</li>
  </ol>
  
  <p>I have no issue in the code I think since:</p>
  
  <ul>
  <li><strong>A</strong> and <strong>B</strong> does get each other ip and port to use</li>
  <li>They are both listening on the port they used to connect to their router when they contacted the server</li>
  <li>They are both connecting to the right ip and port but get timed out (code error <code>10060</code>)</li>
  </ul>
  
  <p>I am missing something ?</p>
  
  <p><strong>EDIT:</strong> With the help of process explorer, I see that one of the client managed to establish a connection to the peer. But the peer doesn't seems to consider the connection to be made.</p>
  
  <p>Here is what I captured with Wireshark. For the sake of the example, the server <strong>S</strong> and the client <strong>A</strong> are on the same PC. The server <strong>S</strong> listens on a specific port (<code>8060</code>) redirected to that PC. <strong>B</strong> still tries to connect on the right IP because it sees that the public address of <strong>A</strong> sent by <strong>S</strong> is <code>localhost</code> and therefore uses the public IP of <strong>S</strong> instead. (I have replaced the public IPs by placeholders)</p>
  
  <p><img src="https://i.stack.imgur.com/BZ07I.png" alt="wireshark"></p>
  
  <p><strong>EDIT 2</strong>: I think the confusion is due to the fact that both incoming and outcoming connection request data are transfered on the same port. Which seems to mess up the connection state because we don't know which socket will get the data from the port. If I quote msdn:</p>
  
  <blockquote>
    <p>The <code>SO_REUSEADDR</code> socket option allows a socket to forcibly bind to a
    port in use by another socket. The second socket calls setsockopt with
    the optname parameter set to <code>SO_REUSEADDR</code> and the optval parameter set
    to a boolean value of <code>TRUE</code> before calling bind on the same port as the
    original socket. <strong>Once the second socket has successfully bound, the
    behavior for all sockets bound to that port is indeterminate.</strong></p>
  </blockquote>
  
  <p>But talking on the same port is required by the TCP Hole Punching technique to <em>open up the holes</em> !</p>