search

BeardedManStudios / ForgeNetworkingRemastered

See various forks, also please join the Forge Community fork of Forge Alloy! -> https://github.com/ForgeAlloyCommunity/ForgeAlloy
https://twitter.com/FarrisFaulds
Apache License 2.0
1.49k stars 305 forks source link

SQP requires nat punchthrough to work outside of LAN (ie with master server list) #328

Open Cerzi opened 5 years ago

Cerzi commented 5 years ago

Version Number and Operating System(s):

b69d15bf34598e2f498c70bf735cc11ec0aa6543

Expected behavior:

Loading a list of servers via a master server list should show game name, player count, ping etc

Actual behavior:

Instead shows "Server Offline". The game can still be connected to as normal using NAT punchthrough

Steps to reproduce:

In settings disable LAN discovery and enable master server list with a working master server (feel free to use mine at 3.19.219.203:15940 if you haven't got one running). Run two instances, and have one host. The server will appear in browser with "Server offline" and no ping/playercount.

Go to your router settings and open the port used by SQP (default 15900). The server info now correctly displays.

I'm not too familiar with the NAT punchthrough code but from looking it it briefly, it looks like it could do with a refactor so it can be re-used by the SQP. Does that sound right? If so I can find some time to take a deeper look at it and potentially fix but I'd need to know if the NatHolePunch server dll would need updating also.

[Optional] Discord Username:

Cerzi

phalasz commented 5 years ago

Well on all dedicated server setups you would open the correct ports without the need for any nat hole punching. This is something that would affect client hosted instances (listen servers).

One option would be to continually poll the master server that has the info as well in case it is a server from there and not a lan discovered one.

Cerzi commented 5 years ago

Yeah sorry, this is specific to non-dedicated servers such as the cube example game (and my own one hehe)

Do you recommend writing additional logic to sit on the master server (alongside the MasterServer and NatPunchThrough dlls) then - or can it be handled by extending TCPMasterClient perhaps?

Not too familiar with this stuff yet but I've noticed right now the NAT punchthrough implementation is only for UDP

phalasz commented 5 years ago

hmm, not sure, I'll have a think on approaches.

phalasz commented 5 years ago

I don't think making sure that a host behind nat and a client behind a different nat can connect is the responsibility of the master server.

This should potentially sit with the NATHolepunch server or something similar although handling this kind of connection is a bit different to how the UDP implementation is done.

Looking at section 4 of https://bford.info/pub/net/p2pnat/ it might be a bit more involved to get TCP Hole punching to work then just refactoring the current implementation that is for UDP.

It might be a good idea to look at Open.NAT to update the current NatHolepunch implementation? 🤔