3 ms·

A polyfill is not required: Code for MSIE et al works fine on other browsers, but some padding is required on the server for the same effect: 2k of padding for

by geocar 11y ago

A polyfill is not required: Code for MSIE et al works fine on other browsers, but some padding is required on the server for the same effect: 2k of padding for MSIE < 10 and Chrome < 13, 4k of padding for Android. Disconnects are difficult to detect as well, so many people recommend sending a message every 15-30 seconds so that you get TCP to notify you, but I recommend just terminating every 15 seconds, and if the client is still there have them reconnect: It wastes a packet, but it means much less load and complexity on the server.

mchahn 11y ago
> Disconnects are difficult to detect as well I am using the npm module rexxars/sse-channel. Maintaining connection has worked very well. During debugging I reload the server and/or client repeatedly and things just stay connected. I'm not sure if this is due to the way chrome handles the connection or the quality of the npm module.
- geocar 11y ago
  I have not looked at rexxars/sse-channel. If you disconnect the client and the client is behind some firewalls (or in some other circumstances), the server might not get notified until it writes something, but the client will reconnect automatically. This means that the server now has two connections, and to handle the error-on-write. If the server periodically writes something, then it will get the error and can recover. If the server does not (however) it will eventually run out of connections. However another approach is to simply set the socket timeout (SO_RCVTIMEO) every time you write. This disconnects the socket automatically, and the client will (if still around) will reconnect. The savings can be significant on a busy server.
  - mchahn 11y ago
    rexxars/sse-channel has a very useful support of history. When a client is disconnected and then reconnected, events that were missed are automatically resent. They use the ID provided by SSE to know what to send. You can count on all events getting through without a lot of overhead. One thing I think is wrong though is that no ID is sent on the first connection so history isn't sent then. My app needs this so I send the history myself on new connections.
mchahn 11y ago
I'm glad to hear other browsers work. I am curious about the padding thing. I don't understand what that has to do with SSE. I thought it was just a new protocol added to the browser.
- geocar 11y ago
  SSE is plain HTTP, and might be illustrative to look[1] at the HTTP response directly so that you can convince yourself of this. EventSource is simply an implementation of a parser of those messages. The problem is that MSIE and Chrome often delay dispatching content-received (XMLHttpRequest readyState=3) handlers until a certain number of bytes have been received (or in certain other circumstances, such as in Chrome's native implementation of EventSource). The bytes-received is solved by simply starting with some padding, and unless you need framing you might find it simpler to just use XMLHttpRequest directly. [1]: http://www.html5rocks.com/en/tutorials/eventsource/basics/ http://www.html5rocks.com/en/tutorials/eventsource/basics/

by geocar 11y ago

mchahn 11y ago

> Disconnects are difficult to detect as well I am using the npm module rexxars/sse-channel. Maintaining connection has worked very well. During debugging I reload the server and/or client repeatedly and things just stay connected. I'm not sure if this is due to the way chrome handles the connection or the quality of the npm module.

geocar 11y ago
I have not looked at rexxars/sse-channel. If you disconnect the client and the client is behind some firewalls (or in some other circumstances), the server might not get notified until it writes something, but the client will reconnect automatically. This means that the server now has two connections, and to handle the error-on-write. If the server periodically writes something, then it will get the error and can recover. If the server does not (however) it will eventually run out of connections. However another approach is to simply set the socket timeout (SO_RCVTIMEO) every time you write. This disconnects the socket automatically, and the client will (if still around) will reconnect. The savings can be significant on a busy server.
- mchahn 11y ago
  rexxars/sse-channel has a very useful support of history. When a client is disconnected and then reconnected, events that were missed are automatically resent. They use the ID provided by SSE to know what to send. You can count on all events getting through without a lot of overhead. One thing I think is wrong though is that no ID is sent on the first connection so history isn't sent then. My app needs this so I send the history myself on new connections.

mchahn 11y ago

I'm glad to hear other browsers work. I am curious about the padding thing. I don't understand what that has to do with SSE. I thought it was just a new protocol added to the browser.

geocar 11y ago
SSE is plain HTTP, and might be illustrative to look[1] at the HTTP response directly so that you can convince yourself of this. EventSource is simply an implementation of a parser of those messages. The problem is that MSIE and Chrome often delay dispatching content-received (XMLHttpRequest readyState=3) handlers until a certain number of bytes have been received (or in certain other circumstances, such as in Chrome's native implementation of EventSource). The bytes-received is solved by simply starting with some padding, and unless you need framing you might find it simpler to just use XMLHttpRequest directly. [1]: http://www.html5rocks.com/en/tutorials/eventsource/basics/ http://www.html5rocks.com/en/tutorials/eventsource/basics/