SSE Connection TTL on server?

[henry-chris]

I haven't been checking the length of my connections and during testing found that some of them could stick around for quite awhile with keepalives.

If you gave the option for a TimeSpan in theServerSentEventsServiceOptions.
Then gave the ServerSentEventClient a creation time.
You could then add something like:

    internal Task SendAsync(ICollection<IServerSentEventsClient> clients, ServerSentEventBytes serverSentEventBytes, CancellationToken cancellationToken)
    {
        List<Task> clientsTasks = null;

        foreach (ServerSentEventsClient client in clients)
        {
            // I know this can be cleaned up, just spitballing.
            if (client.CreatedAt.Add(_clientTtl) < DateTime.UtcNow) 
            {
                // Kill and remove client or do something else here?
            }

Then it would be really easy to control TTL of each connection. However, just adding that check in the browser/client may be enough.

Thoughts?

[tpeczek]

There are several ways to implement this and it wouldn't be too hard.

What I really want is to better understand the use case. SSE connection is alive as long as there is a client at the other end, when the client goes the connection dies. Trying to close the connection earlier seems odd to me. Also if client is a Web client (or any other client fully compliant with the standard) it will automatically reconnect. What value in this case would be having TTL?

[henry-chris]

Ohhh, yes it will re-connect if killed from the server. I did not think about that. It seems like keeping it in the browser would be best then. That way we can prevent re-connections.

What I've found are two things.

1. Users leave tabs open for a looong time. Currently, our maximum session length is X hours without needing to re-authenticate with SSO. So, I'd like to kill the Connections after X hours to prevent stale connections persisting.

2. We have OPS tests that run every ~30 minutes with Selenium. For some reason, those connections are staying active for days at a time before a huge disconnect event happens. We are researching causes in the test env, but to counteract this I was wanting to institute a TTL for the SSE connection.

For now, I've implemented a session length TTL in the browser and it seems like it will stay that way.

[tpeczek]

Implementing this in client seems to be the best approach for your scenario.

Despite that I'm going to keep this open at least for some time as your points caused me to start thinking about session expiration in authorized scenarios and what should happen to stream in such cases. I need to think about this.

[chrisckc]

I implemented something similar by adapting the client (js polyfill) to accept a "CLOSE" event message type, which tells the client to close the connection, otherwise just dropping it from the server side will cause the client to just auto reconnect.

[henry-chris]

@chrisckc That's a very good idea and something I didn't think of. So simple.