Sage 100

@Alnoor Cassim ?????

Thank you Dr Chat:   

How the Sage 100 "Keep Alive" Setting Actually Works and Why It Often No Longer Matters

We were looking at the same Sage KB note about turning off Keep Alives when Sage 100 is running as a service, and it raises a good question: what does this setting even do anymore, and does it matter?

What the Keep Alive setting does

The Keep Alive checkbox in the Sage 100 Client Server Configuration tells the client to send a small "heartbeat" signal to the server at regular intervals. The purpose is to prevent the server or any networking device from assuming the client has gone idle and dropping the connection.

Historically this helped prevent problems like:

• Random disconnects
• "Connection to server has been lost"
• Posting failures during long pauses

What happens if you turn it off

Turning it off simply stops Sage from sending its own heartbeat. The client still works normally. In older environments this could lead to idle disconnects, but not as much today.

Why it often no longer matters

In modern environments, the Sage keep-alive has become mostly irrelevant for several reasons:

1. Windows already provides TCP keep-alive traffic
   Current versions of Windows Server and Windows 10 or 11 send their own low-level TCP heartbeats. This keeps the session alive even with Sage's option disabled.
2. SPC and Azure no longer drop idle connections aggressively
   Earlier generations of cloud hosting had short idle timeouts. Today those timeouts are longer or auto-refreshed, so Sage's own keep-alive adds little value.
3. Sage's Client Server engine communicates more frequently now
   Newer versions of Sage 100 (especially 2023 and newer) have improved RPC calls and background communication that naturally keeps connections active.
4. Modern firewalls and VPNs maintain sessions better
   Idle TCP connections are not dropped as quickly as they were years ago. Most customers now have stateful inspection, RDP keep-alives, and less aggressive timeouts.
5. RDS, AVD and published apps keep the session alive anyway
   Remote Desktop and virtual desktops handle their own session maintenance, so the Sage keep-alive adds nothing on top of that.

Bottom line

Turning off Keep Alives usually does not cause any problems anymore because the OS and hosting platform already handle all the keep-alive behavior that Sage used to rely on. The checkbox simply doesn't have the real impact it had 10 to 15 years ago.

That is why the KB says to turn it off and why most of us have stopped noticing any difference.

Jim Woodhead Principal Consultant, Sage 100 e: jimw@dsdinc.com p: 800-627-9032 x 125 m: 619-990-3946 w: www.dsdinc.com r: Request a Meeting

@Alnoor Cassim ?????

Thank you Dr Chat:   

How the Sage 100 "Keep Alive" Setting Actually Works and Why It Often No Longer Matters

We were looking at the same Sage KB note about turning off Keep Alives when Sage 100 is running as a service, and it raises a good question: what does this setting even do anymore, and does it matter?

What the Keep Alive setting does

The Keep Alive checkbox in the Sage 100 Client Server Configuration tells the client to send a small "heartbeat" signal to the server at regular intervals. The purpose is to prevent the server or any networking device from assuming the client has gone idle and dropping the connection.

Historically this helped prevent problems like:

• Random disconnects
• "Connection to server has been lost"
• Posting failures during long pauses

What happens if you turn it off

Turning it off simply stops Sage from sending its own heartbeat. The client still works normally. In older environments this could lead to idle disconnects, but not as much today.

Why it often no longer matters

In modern environments, the Sage keep-alive has become mostly irrelevant for several reasons:

1. Windows already provides TCP keep-alive traffic
   Current versions of Windows Server and Windows 10 or 11 send their own low-level TCP heartbeats. This keeps the session alive even with Sage's option disabled.
2. SPC and Azure no longer drop idle connections aggressively
   Earlier generations of cloud hosting had short idle timeouts. Today those timeouts are longer or auto-refreshed, so Sage's own keep-alive adds little value.
3. Sage's Client Server engine communicates more frequently now
   Newer versions of Sage 100 (especially 2023 and newer) have improved RPC calls and background communication that naturally keeps connections active.
4. Modern firewalls and VPNs maintain sessions better
   Idle TCP connections are not dropped as quickly as they were years ago. Most customers now have stateful inspection, RDP keep-alives, and less aggressive timeouts.
5. RDS, AVD and published apps keep the session alive anyway
   Remote Desktop and virtual desktops handle their own session maintenance, so the Sage keep-alive adds nothing on top of that.

Bottom line

Turning off Keep Alives usually does not cause any problems anymore because the OS and hosting platform already handle all the keep-alive behavior that Sage used to rely on. The checkbox simply doesn't have the real impact it had 10 to 15 years ago.

That is why the KB says to turn it off and why most of us have stopped noticing any difference.

Jim Woodhead Principal Consultant, Sage 100 e: jimw@dsdinc.com p: 800-627-9032 x 125 m: 619-990-3946 w: www.dsdinc.com r: Request a Meeting

@Alnoor Cassim ?????

@Chris Mengerink - I went overboard so you might be sorry you asked (but at least I didn't confabulate or hallucinate any of this). This response reflects my research and testing from my years working at Sage at the then mothership office in Irvine.

I'm guessing that article, at least from its original writing, is from a long time ago when the 4.x App Server first came into being, and of course it worked better as a desktop app than as a service. Today, the service is "better" than in the past. Today, I would also tell you, service or not, there is limited value in paying attention to the Keep Alives setting.

The concept is that the client side sends a "keep alive" TCP packet thru the o/s every so often for the potential purpose of establishing reconnection of a disconnected session. The server side keeps the disconnected session (the Sage task) open for a period of time based on a timeout value before dropping it.

You really have to ask yourself if this feature is important or not. I would contend that for the majority of installations it is not, simply because it's rare. Disconnects occur typically where you have WiFi connections w/o RDS / Terminal Server and slow remote VPN conections w/o RDS / Terminal Server. So right off the bat, Keep Alives is not that valuable in my opinion.

To utilize this feature, we not only need to tick the box for Keep Alives but the client side has to support it. Well back in early v4.x, but not initially at the inception of the App Server, the box for Spawn Task from Application Server setting was placed into User Maintenance and defaulted to OFF. That still persists today. OFF means you get better performance, especially when loading a Sage task from the Launcher. 

Today, the vast majority of installations have it OFF as that's the default but there are some cases where it's turned ON for some users out of necessity. E.g., some people have their network printers setup in a VLAN and if the alignment of Mercury's magnetic pole matches Mars', a certain cryptic error would occur during a long report or journal preview. Also if the Windows Firewall is turned on at the Sage server and you've setup the App Server as an inbound rule by port (e.g. 10000) instead of the better way to setup by process name (specify pvxwin32.exe / pvxwin64.exe), you would need to set Spawn Task = ON

So the point is it has to be ON for the keep-alive packet to be sent to the App Server and therefore the vast majority of installations are not configured to take advantage of it. Now, let's assume we've set it to ON and keep-alive packets are being sent and that the App Server is retaining disconnected Sage sessions. Is it now possible for us to reconnect a disconnected session? IOW, is it possible for the disconnected Sage screen to wake up and re-establish itself? Well, first the disconnected screen on the wstn has to actually be there. If the screen is lost, then game over. Second, there has to be logic/awareness on the Sage wkstn side to attempt the reconnection. I'm pretty sure there's no attempt.

So there you go. The real answer to your question is "who cares" about Keep Alives because it can't be utilized and its value is minimal today. My opinion. Hope that helps. Sorry for any massive confusion or headache.

------------------------------
Alnoor Cassim
Accounting Systems, Inc. (ASI)
------------------------------

@Chris Mengerink - I went overboard so you might be sorry you asked (but at least I didn't confabulate or hallucinate any of this). This response reflects my research and testing from my years working at Sage at the then mothership office in Irvine.

I'm guessing that article, at least from its original writing, is from a long time ago when the 4.x App Server first came into being, and of course it worked better as a desktop app than as a service. Today, the service is "better" than in the past. Today, I would also tell you, service or not, there is limited value in paying attention to the Keep Alives setting.

The concept is that the client side sends a "keep alive" TCP packet thru the o/s every so often for the potential purpose of establishing reconnection of a disconnected session. The server side keeps the disconnected session (the Sage task) open for a period of time based on a timeout value before dropping it.

You really have to ask yourself if this feature is important or not. I would contend that for the majority of installations it is not, simply because it's rare. Disconnects occur typically where you have WiFi connections w/o RDS / Terminal Server and slow remote VPN conections w/o RDS / Terminal Server. So right off the bat, Keep Alives is not that valuable in my opinion.

To utilize this feature, we not only need to tick the box for Keep Alives but the client side has to support it. Well back in early v4.x, but not initially at the inception of the App Server, the box for Spawn Task from Application Server setting was placed into User Maintenance and defaulted to OFF. That still persists today. OFF means you get better performance, especially when loading a Sage task from the Launcher. 

Today, the vast majority of installations have it OFF as that's the default but there are some cases where it's turned ON for some users out of necessity. E.g., some people have their network printers setup in a VLAN and if the alignment of Mercury's magnetic pole matches Mars', a certain cryptic error would occur during a long report or journal preview. Also if the Windows Firewall is turned on at the Sage server and you've setup the App Server as an inbound rule by port (e.g. 10000) instead of the better way to setup by process name (specify pvxwin32.exe / pvxwin64.exe), you would need to set Spawn Task = ON

So the point is it has to be ON for the keep-alive packet to be sent to the App Server and therefore the vast majority of installations are not configured to take advantage of it. Now, let's assume we've set it to ON and keep-alive packets are being sent and that the App Server is retaining disconnected Sage sessions. Is it now possible for us to reconnect a disconnected session? IOW, is it possible for the disconnected Sage screen to wake up and re-establish itself? Well, first the disconnected screen on the wstn has to actually be there. If the screen is lost, then game over. Second, there has to be logic/awareness on the Sage wkstn side to attempt the reconnection. I'm pretty sure there's no attempt.

So there you go. The real answer to your question is "who cares" about Keep Alives because it can't be utilized and its value is minimal today. My opinion. Hope that helps. Sorry for any massive confusion or headache.

------------------------------
Alnoor Cassim
Accounting Systems, Inc. (ASI)
------------------------------

Thanks @Alnoor Cassim I appreciate the detailed explanation! much better than the Sage KB which basically says nothing other than turn it on/off 

@Chris Mengerink - I went overboard so you might be sorry you asked (but at least I didn't confabulate or hallucinate any of this). This response reflects my research and testing from my years working at Sage at the then mothership office in Irvine.

I'm guessing that article, at least from its original writing, is from a long time ago when the 4.x App Server first came into being, and of course it worked better as a desktop app than as a service. Today, the service is "better" than in the past. Today, I would also tell you, service or not, there is limited value in paying attention to the Keep Alives setting.

The concept is that the client side sends a "keep alive" TCP packet thru the o/s every so often for the potential purpose of establishing reconnection of a disconnected session. The server side keeps the disconnected session (the Sage task) open for a period of time based on a timeout value before dropping it.

You really have to ask yourself if this feature is important or not. I would contend that for the majority of installations it is not, simply because it's rare. Disconnects occur typically where you have WiFi connections w/o RDS / Terminal Server and slow remote VPN conections w/o RDS / Terminal Server. So right off the bat, Keep Alives is not that valuable in my opinion.

To utilize this feature, we not only need to tick the box for Keep Alives but the client side has to support it. Well back in early v4.x, but not initially at the inception of the App Server, the box for Spawn Task from Application Server setting was placed into User Maintenance and defaulted to OFF. That still persists today. OFF means you get better performance, especially when loading a Sage task from the Launcher. 

Today, the vast majority of installations have it OFF as that's the default but there are some cases where it's turned ON for some users out of necessity. E.g., some people have their network printers setup in a VLAN and if the alignment of Mercury's magnetic pole matches Mars', a certain cryptic error would occur during a long report or journal preview. Also if the Windows Firewall is turned on at the Sage server and you've setup the App Server as an inbound rule by port (e.g. 10000) instead of the better way to setup by process name (specify pvxwin32.exe / pvxwin64.exe), you would need to set Spawn Task = ON

So the point is it has to be ON for the keep-alive packet to be sent to the App Server and therefore the vast majority of installations are not configured to take advantage of it. Now, let's assume we've set it to ON and keep-alive packets are being sent and that the App Server is retaining disconnected Sage sessions. Is it now possible for us to reconnect a disconnected session? IOW, is it possible for the disconnected Sage screen to wake up and re-establish itself? Well, first the disconnected screen on the wstn has to actually be there. If the screen is lost, then game over. Second, there has to be logic/awareness on the Sage wkstn side to attempt the reconnection. I'm pretty sure there's no attempt.

So there you go. The real answer to your question is "who cares" about Keep Alives because it can't be utilized and its value is minimal today. My opinion. Hope that helps. Sorry for any massive confusion or headache.

------------------------------
Alnoor Cassim
Accounting Systems, Inc. (ASI)