Campaign to reconnect after internet interruption

[paulsk]

I am trying to leave my FGU campaign up full-time to let players connect and make characters on their own schedule. However, whenever I get an internet interruption, I get a message in the chat window saying, "Lost connection to cloud service. Players may not be able to join game. Attempting to reconnect..."

But my FGU campaign NEVER successfully reconnects, even long after internet access is restored, requiring me to frequently restart the campaign after minor wireless connection hiccups.

Is there any way to fix this?

[LordEntrails]

Welcome!
Sounds like either your security software, hardware, or ISP is closing the connection after being open for a set amount of time. If that is the case, you'll have to figure out which one and how to change it's settings so that it doesn't close the port after x amount of inactivity.

[damned]

Why are you having wireless outages? If you have an unstable network many applications will struggle with maintaining connection.

[Imagix]

Many applications use TCP as the transport protocol, and the transient ports in use would change (FGU does not, it uses UDP. And if the application stack sitting on top of UDP can't handle outages... well, that's a flaw of that networking library). And I don't think that paulsk is even looking for a seamless reconnect mechanism (ie: neither side notices the reconnect except for the delay during the actual outage). I think they're only looking for (on the GM side) "Whups, lost my connection to the cloud. OK, my internet link is back, reconnect to the cloud." without user intervention. And on the player side "Whups, the cloud game went away. Retry connection for a while." Actually, I don't even think they're looking for the player side. I think they'd even be satisfied by the player having to manually reconnect as I think they're more concerned about a new player session trying to start up after the wireless outage.

This could possibly even be eased by having the "cloud" server still listening on port 1802 so that the GMs router doesn't have to get confused about different transient ports having to be opened to accept connections. The player side wouldn't have to keep polling the cloud broker for new connection details. (If the cloud server is actually mediating the connection due to double NATting on the GM side, it would get a little more complex)

(Yes, I do have some idea of what I'm asking for/talking about... I've been writing low-level networking code for over two decades)

[paulsk]

Thanks all. I'm not sure I'm even having outages from my wifi source, but instead after being idle long enough my wifi seems to hiccup, perhaps on my PC's end (although I have turned off Sleeping in my PC power management, so that is not the problem). It usually happens overnight. I play other online games using Discord frequently without Wifi interruption.

Imagix is right that this is not an issue of connections during games. I have not had any live play sessions yet.

[damned]

Many applications use TCP as the transport protocol, and the transient ports in use would change (FGU does not, it uses UDP. And if the application stack sitting on top of UDP can't handle outages... well, that's a flaw of that networking library). And I don't think that paulsk is even looking for a seamless reconnect mechanism (ie: neither side notices the reconnect except for the delay during the actual outage). I think they're only looking for (on the GM side) "Whups, lost my connection to the cloud. OK, my internet link is back, reconnect to the cloud." without user intervention. And on the player side "Whups, the cloud game went away. Retry connection for a while." Actually, I don't even think they're looking for the player side. I think they'd even be satisfied by the player having to manually reconnect as I think they're more concerned about a new player session trying to start up after the wireless outage.

This could possibly even be eased by having the "cloud" server still listening on port 1802 so that the GMs router doesn't have to get confused about different transient ports having to be opened to accept connections. The player side wouldn't have to keep polling the cloud broker for new connection details. (If the cloud server is actually mediating the connection due to double NATting on the GM side, it would get a little more complex)

(Yes, I do have some idea of what I'm asking for/talking about... I've been writing low-level networking code for over two decades)

Almost all protocols and applications have timeout settings. Timeout is reached, session ends. Its pretty standard.

[Imagix]

True, any many such protocols and applications have keepalives/noops in order to not have the session end.

[damned]

Thanks all. I'm not sure I'm even having outages from my wifi source, but instead after being idle long enough my wifi seems to hiccup, perhaps on my PC's end (although I have turned off Sleeping in my PC power management, so that is not the problem). It usually happens overnight. I play other online games using Discord frequently without Wifi interruption.

Imagix is right that this is not an issue of connections during games. I have not had any live play sessions yet.

It may be that the cloud broker is programmed to cleanup "idle" sessions after a period of time.
Probably not conducive to leaving your server online all the time but makes sense in terms of resource management.
The cloud broker service is probably also licensed on a concurrent connection count and it might even be a "feature" that it kills idle sessions...?

[damned]

True, any many such protocols and applications have keepalives/noops in order to not have the session end.

It probably uses a combination of both.
It probably uses keep alives to ensure connections are maintained while everyone is busy discussing rules or on a coffee break and some sort of connection management running over the top that disconnects sessions after they have been idle for x hours or xx minutes or whatever.