Skip to content
This repository has been archived by the owner on Aug 15, 2022. It is now read-only.

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

Open
Cerzi opened this issue Sep 16, 2019 · 4 comments

Comments

@Cerzi
Copy link

Cerzi commented Sep 16, 2019

Version Number and Operating System(s):

b69d15b

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
Copy link
Contributor

phalasz commented Sep 16, 2019

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
Copy link
Author

Cerzi commented Sep 16, 2019

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
Copy link
Contributor

phalasz commented Sep 16, 2019

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

@phalasz
Copy link
Contributor

phalasz commented Sep 17, 2019

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? 🤔

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants