CreggHancock / HolePuncher

UDP Holepunch plugin for Godot

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Example of use and missing variable `starting_game`

azagaya opened this issue · comments

Hi! Do you have any example of usage of this addon?

I created a scene, added a HolePunch node and called start_traversal on the ready function:

hole_punch.start_traversal("Test", Network.settings.server == "1", "Me"+Network.settings.server)

I started the Server.py on a remote server, and i can see peers being connected there, or at least, server prints this:

b'rc:Me1:Test'
b'rc:Me0:Test'

However, hole_punched signal is never emitted, and i never pass the if peer_udp.get_available_packet_count() > 0 instruction.

Is there anything else needed for setting this up?

Also, I noticed the readme mentions a starting_game variable, that is missing.

Thanks in advance!

I think the problem was I was starting first the client and then the server. Sorry for that. Anyways, I still don't see hole_punched signal being emitted, and I'm receiving Receiving no confirm. Starting port cascade I'll continue testing. After this, i could use high level multiplayer to connect peers directly?

Wait, this maybe is happening because i have both devices behind the same router, and i don't see managing local IP to fallback in this case. I'll try connecting to another network and report back.

Yeah that would certainly be the problem. For my own testing I've been using a hotspot off my phone for one device and my router for the other and that seems to work. You're welcome to give that a shot.

And the "starting_game" variable has been removed but I suppose I forgot to delete all the references to that...I'll add that to my todo list, thank you.

Hi! thanks for the response. I tried with two computers on different networks, and still get Receiving no confirm. Starting port cascade and nothing else happens.

So you're never receiving anything from the server? Can you put a print after if peer_udp.get_available_packet_count() > 0 to see what message(s) you are receiving, if anything? Also you might need to adjust any firewall settings you have. During some tests it was necessary for me to disable my firewall since it was blocking initial messages from pinging peers

No, nothing is printed after that if.. this means, I guess, I'm not receiving anything from the server. So this can be a firewall issue? I'll try to disable it on both ends.

Ok, sorry, i was trying to print that in the client. I receive messages after this if clause:

if server_udp.get_available_packet_count()

And this is what i get:

ok:27486
peers:Me1:143.208.44.34:43046

So its doing that fine. Then i get the message Receiving no confirm. Starting port cascade

As a host, i dont see anything printed after if peer_udp.get_available_packet_count() > 0

Hmm so you're receiving the server messages, but you aren't receiving the messages from the peer, and then you attempt to cascade ports in order to ping a port that was opened (Because routers have a habit of moving ports up or down some after opening up). But even after cascading you aren't receiving a message from your peer, so it's likely being blocked by a firewall or your router. Are you sure you have your firewall settings disabled?

Hi! as far as I cant tell, the firewall is disabled, yes. I have two ubuntu machines, with ufw disabled, in two different networks, both routers with firewall disabled. Anyways, for using this technique, you have to ask users to disable firewalls?

Well, it's possible you would yes. I have had it work without doing it, but I've also had to disable it on some networks/devices. It's the problem with P2P in today's world unfortunately, devices are not always going to have the easiest time allowing peers to establish a connection. It's also possible that the holepunch just wont work with your network, and that's why using multiple forms of NAT traversal is often required to make it work right. Usually this starts with UPNP, then falling back to holepunching, and if all else fails either use a relay server for the network transmissions or at the very least inform your users that they may need to disable firewalls, port forward, or have whoever they're playing with host if their router is UPNP compatible. It's possible your Router is blocking the connection.

Are you using a home network and a hotspot for this, or how are you handling it? If you have logs printing for peer messages on both editors can you please tell me if either are printing any incoming peer messages? It's possible you have one peer that is able to get through to the other, but the other one is blocking the connection.

Hi! sorry for the late response, i was doing more tests.
I tried this:

  • On two computers, one with my local wifi, the other with a hotspot made with my cellphone (4G).
  • On one computer in my wifi, and with a cellphone (exported to android)
  • On two different computers in different wifi networks (tested with a team mate)

I guess the problem is on my network then?

Yeah it's possible. You can try maybe using your 4g hotspot to your team mates to check that. But if none of these are receiving messages then it's also possible there is a bug somewhere. I have never tested this with linux if I'm going to be honest, but I doubt that that'd cause any problems here. Another thing you can try doing is increasing the response window or cascade range to give your game a few extra pings before it gives up entirely. One way you can check to see if your pinging the right port is by checking to see what port the server sends you on the device, and then printing the ports that your other device is attempting to ping you at. If they are not within a few integers (the cascade range) then that will be the reason you're failing, and that would mean your router is changing ports beyond what a simple cascade can handle. I haven't experienced this myself, but I've heard this can happen.

Hi! I just tried what you told me. I was connected to 4G on my computer, and tested with a team mate. He was the client and i was the host. In my console i get this:

ok:7789
ok:7790

And in the client, my teammate gets this:

image

So it seems the cascade is pinging the right window.