...
The first recommendation is to force the disconnect of the of the connection after a set amount of consecutive POKEs. Consecutive POKEs means no DATA is actively coming through. It takes a large volume of data to have a connection not have consecutive POKEs. Youcan You can determine what makes sense for your organization, but 5 is a good starting point. 5 Pokes is about 25 seconds. There has been no data in 25 seconds, so you disconnect, let some data build up and, after some period of time, reconnect. You would then wait a few seconds and reconnect. If before there are any DATA events, there are, for example, 5 more consecutive POKEs, you would reconnect again, this time waiting even more time before connecting again. Continue this pattern and increase the reconnect time (to a maximum) until there are some DATA events again. At any point that there is a DATA event, the counters and timers reset. This pattern is recommended because it doesn't unnecessarily leave a connection with no actionable data open, which is good for "connection hygiene" (see recommendation 2 below) and is actually considered good security practice. Only leave connections open that have value.
So, why do connections "go stale"? The fact is TCP/IP and the Internet built on it is designed to work with disruption. Network outages, re-routesreroutes, and other hiccups occur all the time. The longer a connection stays open, the higher the likelihood such a hiccup will impact it. Unfortunately, some connections require long-running connections and are one-way in nature, such as an SSE stream. And, as indicated above, in this scenario, the client has to be responsible for determining the health of the connection. This is because it is receiving data. The server has no way of knowing if the client actually received it, and therefore can't really determine if there is an issue on the connection.
...