Running a Server Externally

[s-ol]

Maybe this? https://love2d.org/forums/viewtopic.php?f=5&t=83585

Also, i have a kinda related question; if two clients connect to the server, in my mind, they could technically connect to each other if the server shares their external ip/ports with each other, right? I mean, that would mean that the server's only a lobby-kind of thing and not authoritative, but still, is it a possibility?

not really, because the user's routers firewalls won't allow it.

actually it's not only about the firewall security thing, but also about mapping ips/ports; when you try to connect to say port 50825 on someone's public IP, the router doesn't know which computer, phone or smart-tv behind it you want to talk to. When the PC makes the request it can basically just remember where the connection came from and keep it up.

There are techniques for getting past this (this is why p2p works) but it's not 'easy' which is why many smaller and older games require you to open ports to host / run dedicated servers that are not firewalled.

[zorg]

not really, because the user's routers firewalls won't allow it.

actually it's not only about the firewall security thing, but also about mapping ips/ports; when you try to connect to say port 50825 on someone's public IP, the router doesn't know which computer, phone or smart-tv behind it you want to talk to. When the PC makes the request it can basically just remember where the connection came from and keep it up.

But this is exactly why i said after using such a "lobby" server; both parties connect to it, the server records the correct ip and port, since they could connect to the dedicated server, then passes those to the other parties, and the clients try to connect directly to each other as an ad-hoc p2p network (yes, the connections between them also matter, but that's a whole nother can of worms i didn't want to touch upon here)

[airstruck]

I second the VPS idea. Check out Amazon's free tier, I've used this (and paid tier) often and have been more than satisfied with the service.

Using a server to assist in holepunching was discussed recently here, where bartbes gave a nice overview of how it would look.

[s-ol]

not really, because the user's routers firewalls won't allow it.

actually it's not only about the firewall security thing, but also about mapping ips/ports; when you try to connect to say port 50825 on someone's public IP, the router doesn't know which computer, phone or smart-tv behind it you want to talk to. When the PC makes the request it can basically just remember where the connection came from and keep it up.

But this is exactly why i said after using such a "lobby" server; both parties connect to it, the server records the correct ip and port, since they could connect to the dedicated server, then passes those to the other parties, and the clients try to connect directly to each other as an ad-hoc p2p network (yes, the connections between them also matter, but that's a whole nother can of worms i didn't want to touch upon here)

yes, maybe my 'not really' was a bit much, i just wanted to get across that it's not as easy as it might sound and maybe not the thing you should start doing networking with. Also it's actually way simpler than I thought, but there probably is still lots of fine-tuning with intervals to do.

[zorg]

Yeah, agreed; and usually, for games, an authoritative server is what you'd want, so my use case isn't that relevant.

[airstruck]

Yeah, agreed; and usually, for games, an authoritative server is what you'd want, so my use case isn't that relevant.

I see no reason why you couldn't have something like "authoritative P2P." The host doesn't need to be playing, it could just host the game and be an authoritative server. The master server can connect players to hosts, that way you're not footing the bill. Sure, the host can cheat, but if they're not actually playing they have no reason to (and if they cheat anyway, players will just use a different host). Not sure if it's actually correct to call it P2P, but the point is the master server doesn't necessarily have to host the games.

The holepunching thing doesn't matter much in that scenario, you can still have the master server list hosts, regardless of whether they need to forward a port.

[s-ol]

Yeah, agreed; and usually, for games, an authoritative server is what you'd want, so my use case isn't that relevant.

I see no reason why you couldn't have something like "authoritative P2P." The host doesn't need to be playing, it could just host the game and be an authoritative server. The master server can connect players to hosts, that way you're not footing the bill. Sure, the host can cheat, but if they're not actually playing they have no reason to (and if they cheat anyway, players will just use a different host). Not sure if it's actually correct to call it P2P, but the point is the master server doesn't necessarily have to host the games.

The holepunching thing doesn't matter much in that scenario, you can still have the master server list hosts, regardless of whether they need to forward a port.

thats basically what CoD is doing (on consoles) as far as I know. If you read up on NAT-punching you will realise you do need that master server in any case - actually also just from a regular game design perspective: if you want people to play without looking up each other's IPs, you need some central place to talk to.

This actually got me thinking, with this method, you could build a cool almost-non-centralized invite system.
As long as your game can figure out it's PCs public IP, you can transform that into something nicely human-readable (choose 256 words, pick one for each byte in the IP) like green-wool-spicy-cat and tell the player to give that to his friend.
The friend's client can then implement the pwnat algorithm and punch a UDP connection.

Figuring out the public IP is the 'centralized' part, but you can probably have a list of 100 public IP-echo servers and be safe for a few years at 0 cost.

[zorg]

Well, i meant something like this:

1. Clients connect to a known adress that is a server.

2a. Server is just a Lobby -> After some people set up a "room" or whatever, the server, based on round-trip times, for example, calculates an initial client-client topology, that doesn't include the server, since that's a constant 1 extra hop; this also means that the server is not authoritative in this case. If clients fall down, they can still communicate with either the server, to reestablish full connection, or they could already have all the connected clients' addresses (and round-trip times), and they can load-balance themselves based on that data.

2b. Server is authoritative -> No matter what, all data will go through the server, since it needs to verify it (since we don't trust the clients).

My original question was more about after connecting to a server that's "open", i.e. not behind a NAT, would simply sharing the client adresses with the other connected clients, and opening connections to those from "both" sides work or not, with or without any special hole-punching.

[airstruck]

If you read up on NAT-punching you will realise you do need that master server in any case

You only need it if players have no other way to discover each other's IP. If people can exchange IPs because they already communicate by some other method, you don't need it.

from a regular game design perspective: if you want people to play without looking up each other's IPs, you need some central place to talk to

True, but if you have something more like dedicated hosts than P2P, hosts can register domains that players can remember and add to their own server lists. Minecraft sold millions of copies on mobile doing it this way. Master list is nice to have, but not essential.

If you did it this way and used the pwnat trick, you can have holepunching without the host needing to be given the client's IP (so, no need for a master server). Although I suppose if people are hosting dedicated game servers, holepunching won't be much of an issue.

after connecting to a server that's "open", i.e. not behind a NAT, would simply sharing the client adresses with the other connected clients, and opening connections to those from "both" sides work or not, with or without any special hole-punching.

If the server's not behind a NAT, you don't need holepunching. The client just needs to be able to find the game server somehow (player knows host's domain name or IP, or hosts register with a "master server" and players pick them from a list, or there's only one game server and clients are hardwired to it).

Edit: I misread your question. What you're describing is holepunching. Have a look here. The thing is, the clients aren't really "connected" to the server, they just told the server how other clients can find them, essentially, and the server tells them how to find other clients they're interested in, and then those clients don't talk to the server anymore, they just talk to each other (so at this point we should call them "peers" and not clients, I guess). This is why you don't actually need the server at all if players can exchange IP addresses some other way; for example if you're just testing a prototype this should be fine, you can write the "master server" code later.