5

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.

Vololodymyr
  • 1,996
  • 5
  • 26
  • 45

2 Answers2

7

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.)

Darren Cook
  • 27,837
  • 13
  • 117
  • 217
  • 1
    Wow, thanks @Darren, i need to check your book. From your unswer i can assume that on server we need to keep messages queue, but how big should be that queue, should i store all events ? – Vololodymyr Oct 14 '19 at 14:58
  • 1
    @Vovan "should i store all events?" That is the ideal, but there may be business reasons against it. Given your description, it sounds like a 5-second queue would cover the 1-2 second gaps you are seeing? So somewhere between 5 seconds and for eternity :-) – Darren Cook Oct 14 '19 at 15:39
  • Thank you @Darren! You gave me an idea. Could you please comment also here https://stackoverflow.com/questions/57325517/how-to-select-eventsource-timeout-value – Vololodymyr Oct 14 '19 at 16:05
  • I'm running into the same question: "should i store all events?". Obviously at some point the server will run out, or as @DarrenCook mentioned, there are business reasons against it. But if a client reconnects and specifies a `Last-Event-Id` that is no longer available. How does the server respond to inform the client that there is a gap? – Tieske Sep 17 '22 at 14:40
  • 1
    @Tieske There is nothing in the event-source API to explicitly handle that case, so you'd handle it as suits your business case. If it is critical they know there was a gap, your server would send back an error. But for most situations I imagining just sending data from the earliest available data would work. – Darren Cook Sep 18 '22 at 15:35
  • just filed an issue: https://github.com/whatwg/html/issues/8297 – Tieske Sep 20 '22 at 09:47
0

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

Sudhakar Ramasamy
  • 1,736
  • 1
  • 8
  • 19