2

I have been searching for a simple UDP C++ library that provides reliability for a while now. I have just come across ENet, which looks perfect, except that I can't find any support for NAT hole punching in the documentation. The internet seems to have a few people discussing this, but I have yet to find a definite answer to whether it is possible.

I already have a third party server that is configured to hand out external ips & ports to clients.

If it is possible, can someone give some pseudocode/steps describing the process?

ThatGuyRightThere
  • 103
  • 1
  • 8

3 Answers3

4

I figured this out. Here's what I did:

  1. Create Host for current client
  2. Connect to 3rd party server
  3. When another client connects to the 3rd party server, it sends out the other clients info to each client
  4. Upon receiving the peers address, each peer attempts a connection to the other peer on the same socket that was used to connect to the server, and begins sending packets to that address. This was initially my problem. I had been sending only a couple of packets, and they could easily be lost. The connection would only work half of the time. I ended up spawning a thread that sent packets until either the connection succeeded or failed.
  5. Connection should be established after a few packets being sent
ThatGuyRightThere
  • 103
  • 1
  • 8
2

Use STUN for Hole Punching and then use ENet.
Communicate with STUN-Server and retrieve public endpoint and NAT type. Make sure the NAT type is open and then continue => use getsockname on socket that used for communicate with STUN-Server, to get local endpoint and then close that socket.
Now create ENet server and initialize it with local endpoint. Now your ENet clients from other computers can connect to server using public endpoint.

moien
  • 999
  • 11
  • 26
-2

UDP may drop packets and it may send packets out of order. Ordering the packets is trivial. But if a packet has been dropped, there can be no way of recovering it. However, many systems that do UDP will provide you with another stream with duplicate data. In which case you can simply create a back up with the secondary stream and then update check if the packet dropped in the first stream is available in the second.

Chani
  • 5,055
  • 15
  • 57
  • 92
  • Unless the two UDP "streams" find a way to use two different routes, they would likely experience the same loss in packets. This is because packet[x] from both stream 1 and stream 2 will be going through the same routers at approx the same times. If a router along the way is dumping packets it will likely drop packet[x] from both streams. In truth, it may easily drop packet[x-5] to packet[x+5] from both streams. There's a small chance some packets in this range might make it from one stream and not the other, but not enough of a chance to count on all packets arriving between both streams – JSON Nov 21 '14 at 08:46