4 ms·

I've used websockets in several projects now. They are more problematic than I originally thought they would be. On my current project I'm using server-sent-e

by mchahn 11y ago

I've used websockets in several projects now. They are more problematic than I originally thought they would be. On my current project I'm using server-sent-events (SSE) for single-duplex pushing to the client. I'm using AJAX calls for the other direction. So far the experience has been awesome. Very light-weight and performant. Just a dozen lines of code on the client with no framework. Caveat: Doesn't work with IE. A polyfill is required. I am very lucky on this project that I don't need to support IE.

xjia 11y ago
So what were the problems you've encountered?
- mchahn 11y ago
  See the article (grin). It was mostly due to connection problems. I had to add yet another layer on top of the frameworks I used. Also I effectively had three channels. The two in the websockets and the ajax which I needed for historical reasons. Just an overall feeling of heavy weight compared to the very light SSE.
  - xjia 11y ago
    I see.. Do you think it would be better for a project starting from scratch? i.e. without that two "old" channels
    - mchahn 11y ago
      > Do you think it would be better for a project starting from scratch? At this moment, yes. Now that I know you can use SSE with any browser, I'm not sure what advantage there is with websockets. Maybe someone can explain.
nailer 11y ago
+1 HTML5 SSE. They fit in with REST, aren't an extra protocol, and are way easier to debug when compared to websockets. An important addition to your recommendations: make sure you disable gzip on the SSE route, or at least flush the gzip otherwise it won't send.
- tehbeard 11y ago
  Why do I have the feeling this is why I encountered weird delays with data when we tried SSE.
  - nailer 11y ago
    Probably. SSE either just works, or blood starts coming out your nose because you've had a stroke debugging why hello world doesn't work, in which case: you have gzip turned on.
seivan 11y ago
Out of curiosity, do you know if SSE would pipe through AWS Cloudfront? I can't find any information on this. Performance isn't an issue, it's just that I don't want to expose the backend directly so all requests go through AWS Cloudfront, but I'm stuck hard coding the url to the backend for SSE. But yeah I agree SSE is much nicer, especially being built in Rails >= 3 and doing regular post requests the other way around.
- mchahn 11y ago
  Sorry, I know nothing about cloudfront.
- csears 11y ago
  The CloudFront docs don't mention SSE support and they definitely don't support WebSockets today. That said, with CloudFront Custom Origins you can do "Transfer-Encoding: chunked" [1] which will cause CDN server to deliver content to the client as it is sent by your application. That seems like it would be compatible with SSE. Unfortunately it also has a 30 second idle timeout [2] which may be a showstopper depending on how frequently your app sends event. [1] http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html#ResponseCustomTransferEncoding http://docs.aws.amazon.com/AmazonCloudFront/latest/Developer... [2] http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html#request-custom-request-timeout http://docs.aws.amazon.com/AmazonCloudFront/latest/Developer...
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.
empath75 11y ago
The only thing I've used websockets for is a JavaScript VNC server.

by mchahn 11y ago

xjia 11y ago

So what were the problems you've encountered?

mchahn 11y ago
See the article (grin). It was mostly due to connection problems. I had to add yet another layer on top of the frameworks I used. Also I effectively had three channels. The two in the websockets and the ajax which I needed for historical reasons. Just an overall feeling of heavy weight compared to the very light SSE.
- xjia 11y ago
  I see.. Do you think it would be better for a project starting from scratch? i.e. without that two "old" channels
  - mchahn 11y ago
    > Do you think it would be better for a project starting from scratch? At this moment, yes. Now that I know you can use SSE with any browser, I'm not sure what advantage there is with websockets. Maybe someone can explain.

nailer 11y ago

+1 HTML5 SSE. They fit in with REST, aren't an extra protocol, and are way easier to debug when compared to websockets. An important addition to your recommendations: make sure you disable gzip on the SSE route, or at least flush the gzip otherwise it won't send.

tehbeard 11y ago
Why do I have the feeling this is why I encountered weird delays with data when we tried SSE.
- nailer 11y ago
  Probably. SSE either just works, or blood starts coming out your nose because you've had a stroke debugging why hello world doesn't work, in which case: you have gzip turned on.

seivan 11y ago

Out of curiosity, do you know if SSE would pipe through AWS Cloudfront? I can't find any information on this. Performance isn't an issue, it's just that I don't want to expose the backend directly so all requests go through AWS Cloudfront, but I'm stuck hard coding the url to the backend for SSE. But yeah I agree SSE is much nicer, especially being built in Rails >= 3 and doing regular post requests the other way around.

mchahn 11y ago
Sorry, I know nothing about cloudfront.
csears 11y ago
The CloudFront docs don't mention SSE support and they definitely don't support WebSockets today. That said, with CloudFront Custom Origins you can do "Transfer-Encoding: chunked" [1] which will cause CDN server to deliver content to the client as it is sent by your application. That seems like it would be compatible with SSE. Unfortunately it also has a 30 second idle timeout [2] which may be a showstopper depending on how frequently your app sends event. [1] http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html#ResponseCustomTransferEncoding http://docs.aws.amazon.com/AmazonCloudFront/latest/Developer... [2] http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html#request-custom-request-timeout http://docs.aws.amazon.com/AmazonCloudFront/latest/Developer...

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.

empath75 11y ago

The only thing I've used websockets for is a JavaScript VNC server.