2
votes

In our application we have SSE connection with living time 5 minutes, after 5 minutes server closes the connection and client reconnect automatically.

But here the problem: while client reconnecting, there might some event happened on backend and it will not be passed to SSE connection, because it’s not established yet.

So there are some time slots 1-2sec when we may loose events.

How we can handle this case ? What is your opinion ?

From my vision we only have one choice: after every SSE reconnect do additional GET requests on server to refresh data.

2
why do you disconnect & reconnect?Sudhakar Ramasamy
@SudhakarRS, SSE works on top of HTTP connection. In our current infrustructure we have a limit of HTTP iddle timeout on load balancer.Vovan

2 Answers

3
votes

This is exactly what the Last-Event-ID HTTP header in the SSE protocol is designed for.

On the server side you should look for that header when you get a new connection. If it is set, stream the missing data gap to them, immediately. And you should set the id header for each message you push out, to some unique identifier.

On the client side, for your particular use case, you do not need to do anything: when SSE reconnect runs it sends that header automatically, using the id of the last data it had received.

In chapter 5 of my book Data Push Apps with HTML5 SSE, I argue you should also include that same unique id, explcitly, in the JSON data packet you push out, and you should support the Last-Event-ID being given as a POST/GET argument as well. This gives you the flexibility to work with the long-polling alternative approaches to SSE, and also means it can work if the reconnect came from the client-side rather than the server-side. (The former would be for supporting older browsers, though that matter less and less as IE dies out; the latter would be needed if you implement your own keep-alive mechanism.)

1
votes

You can queue of events in the server and deque the events when the client is active.

Regardless of the client's connection status, just add all the events to queue.

When the client is connected, deque all the events from the queue.

Instead of sending the message directly to clients the application sends it to the broker. Then the broker sends the message to all subscribers (which may include the original sender) and they send it to the clients.

Refer https://www.tpeczek.com/2017/09/server-sent-events-or-websockets.html