Server-Sent Events: an alternative to WebSockets
1–10 of 266 posts
Re: Server-Sent Events: an alternative to WebSockets
#2I tried out server side events, but they are still quite troubling with the lack of headers and cookies. I remember I needed some polyfill version which gave more issues.
Re: Server-Sent Events: an alternative to WebSockets
#3---
WebSockets cannot benefit from any HTTP feature. That is:
No support for compression
No support for HTTP/2 multiplexing
Potential issues with proxies
No protection from Cross-Site HijackingIs that true? The web never cease to amaze.
Re: Server-Sent Events: an alternative to WebSockets
#4I can’t find any downsides of SSE presented. My experience is that they’re nice in theory but the devils in the details. The biggest issue being that you basically need http/2 to make them practical.
Re: Server-Sent Events: an alternative to WebSockets
#5--- WebSockets cannot benefit from any HTTP feature. That is: No support for compression No support for HTTP/2 multiplexing Potential issues with proxies No protection from Cross-Site Hijacking --- Is that true? The web never cease to amaze.
WebSockets support compression (ofc, the article goes on to detail this & point out flaws. I'd argue that compression is not generally useful in web sockets in the context of many small messages, so it makes sense to be default-off for servers as it's something which should be enabled explicitly when necessary, but the client should be default-on since the server is where the resource usage decision matters)
I don't see why WebSockets should benefit from HTTP. Besides the handshake to setup the bidirectional channel, they're a separate protocol. I'll agree that servers should think twice about using them: they necessitate a lack of statelessness & HTTP has plenty of benefits for most web usecases
Still, this is a good article. SSE looks interesting. I host an online card game openEtG, which is far enough from real time that SSE could potentially be a way to reduce having a connection to every user on the site
Re: Server-Sent Events: an alternative to WebSockets
#6I can’t find any downsides of SSE presented. My experience is that they’re nice in theory but the devils in the details. The biggest issue being that you basically need http/2 to make them practical.
Absolutely not, HTTP/1.1 is the way to make SSE fly:
https://github.com/tinspin/rupy/wiki/Comet-Stream
Old page, search for "event-stream"... Comet-stream is a collection of techniques of which SSE is one.
My experience is that SSE goes through anti-viruses better!
Re: Server-Sent Events: an alternative to WebSockets
#7I tried out server side events, but they are still quite troubling with the lack of headers and cookies. I remember I needed some polyfill version which gave more issues.
How do you mean lack of headers and cookies?
That is wrong. Edit: Actually it seems correct (a javascript problem, not SSE problem) but it's a non-problem if you use a parameter for that data instead and read it on the server.
Re: Server-Sent Events: an alternative to WebSockets
#8Does SSE offer support for capturing connect/disconnect situations?
Re: Server-Sent Events: an alternative to WebSockets
#9I like them, they surprisingly easy to use..
One example where i found it to be not the perfect solution was with a web turn-based game.
The SSE was perfect to update gamestate to all clients, but to have great latency from the players point of view whenever the player had to do something, it was via a normal ajax-http call.
Eventually I had to switch to uglier websockets and keep connection open.
Http-keep-alive was that reliable.
Re: Server-Sent Events: an alternative to WebSockets
#10--- WebSockets cannot benefit from any HTTP feature. That is: No support for compression No support for HTTP/2 multiplexing Potential issues with proxies No protection from Cross-Site Hijacking --- Is that true? The web never cease to amaze.
The problem with WebSockets is that hey are:
1) More complex and binary so you cannot debug them as easily, specially on live and specially if you use HTTPS.
2) The implementations don't parallelize the processing, with Comet-Stream + SSE you just need to find a application server that has concurrency and you are set to scale on the entire machines cores.
3) WebSockets still have more problems with Firewalls.