Nope. However, it will allow you to contact any connected client at will from the server-side. Try doing that with XHR without constantly polling the server.
What's wrong with long polling and keep-alive connections, handled with evented socket code on the server side? Is it mainly because of the HTTP request overhead?
With long-polling you have reconnect after every message, which is a very expensive operation (relatively speaking). HTTP headers often form the bulk of the request, and the number of connections you have to maintain is high. All of these things add up.
> Is it mainly because of the HTTP request overhead?
Aside from the overhead you and others mention, there is a bigger problem. For most server-side languages, once a request is initiated, it is very difficult to feed new data into that request and make it perform additional functions. Most requests get their input data from GET or POST. What if an external server outside of the one that is handling the request needs to contact one of the clients?
Using long polling/SSE, you essentially have to have the thread/process handling the request also poll any external sources for information for any potential events that might need to be triggered. This turns into a huge mess very quickly. Especially since each polling/SSE request thread/process is isolated from the rest, forcing you to do really funky stuff to coordinate everything.
This isn't as much of a problem with web sockets. Your web socket server has access to all of the connected clients and you can create a web socket interface in any external servers to allow them to talk directly to the proper clients. It's cleaner.
Web sockets isn't perfect. I had to implement a proper client for web sockets in PHP so that it can talk to my Node.JS websocket server. It was horrible. But it was less horrible than setting all of that up with long polling.
There is nothing inherently wrong with long polling, but when you consider the overhead of a small payload (let's say 4 bytes for fun) the HTTP request headers add significant overhead. WebSockets have very little overhead for a 4 byte payload (2-4 bytes depending on masking (4 for the spec)) ... and the latency is less than half. It's just more efficient.
Pretty much. That, and I don't think you can really send data back to the server over a long-polling connection - if you can, it's a giant hack - but WebSockets is explicitly designed for bidirectionality.
SSE, on the other hand, basically is long-polling and keep-alives, but with better defined behavior and a nicer API on the client side.
Or... don't have to deal with concurrent editing/locking mechanism? WebSockets do that for us?