We're using SSE as a reliable Server -> Browser streaming mechanism where the server maintains a message queue per user connection. The server needs to buffer all messages until it receives an acknowledgment for a given message (ACK). The server sometimes needs to indicate to the Browser that the message queue has become too large and the browser should send an ACK as soon as possible. One way the server can indicate that it needs an ACK is to end the HTTP Response causing the event-source stream to automatically reconnect with the "Last-Event-ID" header. We call this an "in-band ACK", where the server sends a "request for ACK" by ending the HTTP response (using transfer-encoding chunked and sending the 0 chunk, for instance.)<br>
<br>Normally, a message's latency is  the time it takes to travel from the server to the browser, or one leg. For in band ACKing, it takes 3 legs to deliver the next message after an ACK request: 1) Server -> Browser (end of response), 2) Browser -> Server (new request), 3) Server -> Browser (next message). A solution to this problem is to make a second concurrent http request that represents the ACK; this we call an "out-of-band ACK". <br>
<br>Unfortunately, the current Server-sent Events specification provides no way for a user of the event-source API to know the value of the lastEventId,  thus making it impossible to send an ACK out-of-band. We have two proposals, either of which can solve this problem.<br>
<br>1) Expose the id attribute on each dispatched event. This allows us to send out-of-band ACKs as required. The downside is that we would need to extend the MessageEvent interface. <br><br>2) Expose an add/remove EventListener on the event-source dom element that dispatches whenever the last event id for an event source is changed. The event generated by a change in the last event id would have that id value as an attribute, as well as the href for the event source associated with the id. <br>
<br>We prefer the first solution, but any solution would be good. Any suggestions for a better solution?<br><br><br>-Michael Carter<br>