Technical description for cloud games

Looking forward to the demo users being able to connect soon, I can't see where there has been a discussion of what, technically, happens when hosting a cloud game.

As I understand, the game server is still My PC, as the DM, but the FG Cloud Service simply brokers connections, so you no longer need holes in the firewall to make it work. Is that correct?

Can we get a technical discussion around how it does that, from a network perspective, or can you please point me to where this might have been laid out before?

Thanks.

Here's the documentation I'm aware of: https://fantasygroundsunity.atlassia...Hosting+a+Game but it doesn't answer your question about behind the scenes tech.

Maybe a dev will chime in with more details... but also... it may well be that the process is just incomprehensible to normal humans at this point. The common way to handle this is some combination/variation of STUN, TURN, and ICE, which are well known techniques for matchmaking peer-to-peer (if possible, or server relayed if necessary) connections in adverse network conditions. If they're doing that (and I don't know that they are) the good news is that it pretty much always works as long as you can visit the Fantasy Grounds website from your browser... so it's much less likely that you'll have a need to understand it. The bad news is that the discovery workflow and packet paths are highly variable depending on network conditions, and it's basically impossible to understand what happens and why in a specific situation unless you're a professional network engineer (and often super difficult even if you are).

Some background first...

Generally, port forwarding is required for inbound connections coming towards a NAT router (home routers are Network Address Translation routers) because while the connection will successfully reach the external interface on your router, it will have no idea which of possibly dozens of machines on your network that connection should continue on towards. Your router doesn't inherently know that some machine inside your network has the FG server software listening on the correct port. So, you set up a port forward rule that tells your router basically "any traffic that comes in on port 1802 should be forwarded on to this internal IP address."

Port forwarding is not required for connections initiated in the other direction. When you make an outgoing connection, for example, to fetch a website, your router knows where the original request came from (your machine's internal IP address) so it doesn't need to be told where to send the data that comes back as part of that connection (the website you asked to fetch). The router automatically maintains a table of which connections were created by which internal systems. So, nothing special needs to be done to your router for that to work.


Now, here's what connection brokering typically does... Both the DM's and the players' FG instances are initiating the connections to the server in the cloud (just like your web browser does to fetch a website). Then since the cloud server already has established connections to everyone involved, it is able to facilitate communication between DM and players without any need for port forwarding anywhere. This is also typically called NAT traversal.

FGU's implementation of this idea is probably more complicated than this, but I believe this is the basic idea. Someone with more under-the-hood knowledge from SW could give a more technical description of how they're doing it.

When using the cloud server option; a server instance is actually hosted on a SmiteWorks server, instead of on your local machine. A server instance in this scenario is purely a server to pass messages and files between the GM and player clients. The GM client is still the "authoritative server" for all purposes of running the game session, and providing files.

Regards,
JPG

So while it removes the need to port forward and do exotic setups it will slow down every transaction

Quote:

---

Originally Posted by Bidmaron

So while it removes the need to port forward and do exotic setups it will slow down every transaction

---

Did you measure this or are you speculating? There are many first person shooter, esports, racing, and other fast twitch games that relay network data through a central server like this, and they work reasonably well. FG is much less demanding than these fast-twitch systems and there is no reason a relay architecture can't have excellent performance.

The reality is it will be slower but this will be measured in 10s or 100s of milliseconds and will most likely be transparent to all parties.

Any measurements right now will be bogus because they are still working the network optimizations. I didn’t mean to imply it would be appreciable but it will obviously be a tax.