Web socket - Ajax - long poll

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.

Here is a chart of Browsers that supports WebSockets right now.

Comparison of different communication techniques:

• 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.

LONG POLLING VS SHORT POLLING

There are 2 ways to create real-time content, the push and the pull technologies. Push is when the server initiates the traction, the server is “pushing” data into the client. This is in contrast with pull where the client initiates the transaction, the client “pulls” data from the server.

Implementing push is more efficient than pull, but a bit more complicated to implement. On the other hand, pulling is easier.

Polling, or polled operation, in computer science, refers to actively sampling the status of an external device by a client program as a synchronous activity. It’s basically just a continuous ajax request to a server. And it works with your typical LAMP server.

HOW TO IMPLEMENT POLLING

There are 2 types of polling, namely, Short Polling and Long Polling. Both of them are implemented using ajax technology and are both commonly used in today’s websites.

SHORT POLLING

The easier of the two is the short polling. Basically, it uses a timer and asks the server if data is available and the server returns it. It’s ROUGHLY similar to refreshing the page in a regular interval. It useful when you don’t need your data to be exactly real-time or data changes are not too often. This method uses less server resources.

LONG POLLING

Long Polling is the more advanced of the two and a bit more complex. Instead of using a timer, it has an event based algorithm as summarized below.

1. Client sends the ajax request AJAX
2. The server checks if there are changes in the data
3. IF yes, the returns the data and go back to #1
4. IF no, the server waits for a very short time and goes back to #2

Long polling is useful when you want your data to be extremely close to exact real-time. It’s because instead of waiting for a timer, it actually waits for something to happen until it makes a move. But this method has a downside, it uses more server resources than its counterpart since the server-side script will always be running in long extents instead of just short bursts.

CONCLUSION

Use Short polling for not so real-time updates and use only Long Polling when you really need it to be real-time like in a chat box. Then, don’t use both of them for extremely heavy real-time data. 

References:
http://www.ibm.com/developerworks/library/wa-aj-streamline/
http://www.ibm.com/developerworks/library/wa-reverseajax2/