UDP hole punching

[bartbes]

Then immediatelly change the socket to receive something from that server.

That is entirely unnecessary, the socket works both ways out of the box.

I did notice you have a relatively short timeout and hang up immediately, what happens if you wait (much) longer? Also note that you want to be doing something with the results of receivefrom.

The app runs on customers device and is in the customers own network. So if the do not forward their port the app is not going to work. And thats what I wanted to overcome. They should not configure anything. It should just work.

That should also just happen. NAT is annoying for the end that gets connected to, not whatever end initiates because otherwise it would just utterly and completely break the internet. You don't forward ports to browse websites either, do you?

[Fenrir]

Hey @Fenrir

I'm facing the similar problem.

I want several clients to have a separate sqlite database, but keep all of the clients in sync. I use UDP for this and on the local network it works. But it would be better if I could sync from anywhere I have an internet connection. So, then I had the idea of having a remote server with open port 42000.

The remote server would basically work as a share station ("lobby") for UDP messages. Each client can send some message to the remote server and also at the same time listen for others messages and pick up the ones it needs.

But frankly that didn't work. It seems like the message is send, but I can not listen to the remote server. If I try to see what my :getsockname() is .. it's the local IP of my mashine instead of the remote servers ip, although I was bound to it.

Turn's out I maybe need to use some NAT hole punching technique to connect the wires... Would you share your code with me please?, so I get an idea what to do? I basically understand the concept, but don't know where to start. Do I need some script to run on the remote server S which connects Client A & Client B?

I'm quite rusty on this subject, not sure if I can be helpful. But from what I remember, the idea is:

=> On your public server (you must be sure than connecting to this server is not an issue, that its IP is public and not behind a NAT), you need a script that makes 3 things:
- When a client connects to it, send back to the client its public IP (I've been using socket for it, not enet, as we need a TCP connection to retrieve the IP, we can't get it from enet if I remember correctly).
- Now that the the client is aware of its private and public IPs, reconnect to the server using UDP (via enet in my case) to create a hole in the port I need and to ask to the server the address of the machine(s) you want to connect to (getting both private and public IPs).
- Notify the other machine(s) that a new client is here and wants to connect, and provide its IPs.

=> And now the idea to be sure to punch a hole for the UDP connection is to try to create a connection from all sides with both the public and private IPs, and as soon as one connection succeed, you can discard the others.

But as said before, if the idea is just to connect to a server and not create a peer-to-peer connection between clients behind NATs, hole punching is useless for you, as to make it work you need in all cases a server well configured to accept UDP connections in the port you'll use.

[jack0088]

@bartbes Yes I tried increase timeout, but nothing. I also print out msg,ip,port gotten from receivefrom() - that code above was just pseudo for what I roughly have. As I said it works locally.

@fenrir & @bartbes Thank you both so far. I now see I don't needthe Nat punch. --- As I described: basically I need a peer to peer connection over the internet. The issue is only that each client does NOT know the public ip of the others but somehow needs to talk to them. The idea was using the remote server as a proxy, kinda.

So if I don't need a Nat hole, why does it not work.. I don't get it. Could I post you some code snippet so you guys could review it (if you have a minute to spend on it)??

(You could even try yourself as the public server ip and port are in there. But I'm at work right now, so I could post the code in about 4 hours)

[alloyed]

If you have a server you'd like to proxy through, then you don't need NAT punching because you can use the server rather than connecting to each peer directly

so instead of the data going
peer <--> peer
you do
peer <--> server <--> peer
on the server side this just means when you recieve a message all you need to do is figure out which clients it was intended for and pass it on. That would roughly look like:

Code: Select all

function server.receive(peer, message)
  local recipients = get_recipients_for(message)
  for _, peer in ipairs(recipients) do
    peer:send(message)
  end
end

[jack0088]

yes, you exactly understood what I meant. peer<->server<->peer is the schema I thought of.

Do I understand you correctly when I assume that I have to run a SCRIPT on that remote server (proxy) which forwards the messages to the right peer?

That was what I was missing then. Everything I sent was received by the proxy and therefor consumed, so that the peer on the other end did not receive anything because the message was targetet at the server ip, instead of the peer ip.. Ahhh I seee..

[Nuthen224]

@Fenrir, I just wanted to mention that you can get the public IP in lua-enet using tostring(peer)
Also thank you for the information.

@jack, if you could forward messages via the server it would work, and a single server would be enough to handle many sessions at once (if the messages are infrequent).

[jack0088]

@alloyed, @bartbes, @Fenrir Thank all of you guys! You really helped me understand my issue. I think I know what to do and how to do it. Great!