Tuesday, December 31, 2013

So I'm building a small chat application for friends and, as I'm building it, I've been going back and forth about how to get information in a timely manner that is not manual or as rudimentary as forcing a page refresh.
That said, I've put in simple Ajax but alas, it's with constant hits to the server via a short timer. Someone suggested to me (on another thread of mine here on SO) about long/short polling etc, and as I researched, I ran across HTML5 websockets...
It SEEMS easy to implement and although not full spec yet (I think) (plus I think only some browsers support it) I'm wondering, in a HTML5 WebSockets vs AJAX long/short polling, what are the advantages/disadvantages to them?
Since I am learning, I don't want to learn both if one is better... They kind of do the same thing (I'm assuming) but I'm wondering are there certain scenarios where one would use one technique over the other? Or is HTML5 WS supposed to take over in general?
Any tips/relative links etc...I'd appreciate.
Thanks in advance.
share|improve this question
add comment

4 Answers

up vote23down voteaccepted
WebSockets - is definitely the future. Long polling is dirty workaround of preventing creating connections for each request like AJAX does. But long polling was created when WebSockets didn't existed. Now due WebSockets, Long Polling is going away.
I recommend to learn WebSockets.
Here is list of Browsers that supports WebSockets right now. I believe that in half a year all major browsers will have full support, and in one year it will become a standard. For now it is working well based on my experience in Firefox, Chrome, Safari, iOS, IE10.
As well some clearance:
  • AJAX - create connection to server on each request, sends request (with possible extra data as like request methods GET, POST, PUT, DELETE, .. , and arguments in url), and gets response from server. Then connection closes. It is single request > response for each AJAX call.
  • Long poll - creates connection to server like AJAX does, but keep-alive connection open for some time (not long though), during connection open client can receive data from server. Client have to reconnect periodically after connection is closed due to timeouts. On server side it still treated like HTTP request same as AJAX.
  • WebSockets - create TCP connection to server, and keep is as long as needed. Server or client can easily close it. Bidirectional communication - so server and client can exchange data both directions at any time. It is very efficient if application requires frequent messages. WebSockets do have data framing that includes masking for each message sent from client to server so data is simply encrypted.
  • WebRTC - Is peer-to-peer type of transport and is transport-agnostic so uses UDP, TCP or even more abstract layers. By design it allows to transport data in reliable as well as unreliable ways. This is generally used for high volume data transfer such as video/audio streaming where reliability - is secondary and few frames or reduction in quality progression can be sacrificed in favour of response time and at least delivering something. Both sides (peers) can push data to each other independently. While it can be used totally independent from any centralised servers it still require some way of exchanging endPoints data, where in most cases developers still use centralised servers to "link" peers. This is required only to exchange essential data for connection establishing - after connection is established server on aside is not required.
Main advantage of WebSockets for server, is that it is not HTTP request (after handshake), but proper message based communication protocol. That allows you to achieve huge performance and architecture advantages. For example in node.js you can share same memory for different socket connections, so that way they can access shared variables. So you don't need to use database as exchange point in the middle (like with AJAX or Long Polling and for example PHP). You can store data in RAM, or even republish between sockets straight away.
Remember that WebSockets generally have very different approach of logic for networking, more like real-time games had all this time, and not like http.
share|improve this answer
Tell me if I'm wrong but even though WebSocket provides a lot of improvement it does not completely overlap the functionality of long polling. For instance you cannot just swap comet for websocket to poll a REST api. –  Reno Aug 7 '13 at 9:23
It's not about compatibility it self. Most important that it is about to fully rethink the way communication is happening. As RESTful APIs work with Request>Response pattern, bi-directional communication here would be pointless. So trying to use WebSockets to query RESTful API - is a bit weird attempt, and can't see any benefit of it at all. If you need data from RESTful API but in real-time manner, then you create WebSockets api to push data that will work with bidirectional communication like WebSockets. You are trying to compare things in angle that they are not comparable :) –  Maksims Mihejevs Aug 7 '13 at 15:00
add comment
For chat applications or any other application that is in constant conversation with the server,WebSockets are the best option. However, you can only use WebSockets with a server that supports them, so that may limit your ability to use them if you cannot install the required libraries. In which case, you would need to use Long Polling to obtain similar functionality.
share|improve this answer
WebSockets are supported by every server... You just need to install node.js or something similar. –  micApr 5 '12 at 12:46
Tweaked a bit to explain that yes any server will support WebSockets. However, if you are using hosting service, you may not be able to use them. –  Brant Olsen Apr 5 '12 at 12:49
not at heroku they are not supported yet –  Muhammad Umer Jul 21 '13 at 23:09
add comment
An obvious disdvantage of polling over sockets is that it will open useless connections to your server when there is no new data on the server.
Sockets will only create a connection when a new event happened.
On servers that create a lot of events and where sockets will therefore throttle your connection you best use interval polling.
On servers with a low data exchange rate its often best to use sockets.
share|improve this answer
add comment