In What Situations Would Ajax Long/Short Polling Be Preferred Over Html5 Websockets

In what situations would AJAX long/short polling be preferred over HTML5 WebSockets?

WebSockets is definitely the future now.

Long polling is a dirty workaround to prevent creating connections for each request like AJAX does - but long polling was created when WebSockets didn't exist. Now due to WebSockets,
long polling is going away no more.

WebRTC allows for peer-to-peer communication.

I recommend learning WebSockets.

Comparison:

of different communication techniques on the web

• AJAX - request → response. Creates a connection to the server, sends request headers with optional data, gets a response from the server, and closes the connection.
  Supported in all major browsers.

• Long poll - request → wait → response. Creates a connection to the server like AJAX does, but maintains a keep-alive connection open for some time (not long though). During connection, the open client can receive data from the server. The client has to reconnect periodically after the connection is closed, due to timeouts or data eof. On server side it is still treated like an HTTP request, same as AJAX, except the answer on request will happen now or some time in the future, defined by the application logic.
  support chart (full) | wikipedia

• WebSockets - client ↔ server. Create a TCP connection to the server, and keep it open as long as needed. The server or client can easily close the connection. The client goes through an HTTP compatible handshake process. If it succeeds, then the server and client can exchange data in both directions at any time. It is efficient if the application requires frequent data exchange in both ways. WebSockets do have data framing that includes masking for each message sent from client to server, so data is simply encrypted.
  support chart (very good) | wikipedia

• WebRTC - peer ↔ peer. Transport to establish communication between clients and is transport-agnostic, so it can use UDP, TCP or even more abstract layers. This is generally used for high volume data transfer, such as video/audio streaming, where reliability is secondary and a few frames or reduction in quality progression can be sacrificed in favour of response time and, at least, some data transfer. Both sides (peers) can push data to each other independently. While it can be used totally independent from any centralised servers, it still requires 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 establishing a connection, after which a centralised server is not required.
  support chart (medium) | wikipedia

• Server-Sent Events - client ← server. Client establishes persistent and long-term connection to server. Only the server can send data to a client. If the client wants to send data to the server, it would require the use of another technology/protocol to do so. This protocol is HTTP compatible and simple to implement in most server-side platforms. This is a preferable protocol to be used instead of Long Polling. support chart (good, except IE) | wikipedia

Advantages:

The main advantage of WebSockets server-side, is that it is not an HTTP request (after handshake), but a proper message based communication protocol. This enables you to achieve huge performance and architecture advantages. For example, in node.js, you can share the same memory for different socket connections, so they can each access shared variables. Therefore, you don't need to use a database as an exchange point in the middle (like with AJAX or Long Polling with a language like PHP).
You can store data in RAM, or even republish between sockets straight away.

Security considerations

People are often concerned about the security of WebSockets. The reality is that it makes little difference or even puts WebSockets as better option. First of all, with AJAX, there is a higher chance of MITM, as each request is a new TCP connection that is traversing through internet infrastructure. With WebSockets, once it's connected it is far more challenging to intercept in between, with additionally enforced frame masking when data is streamed from client to server as well as additional compression, which requires more effort to probe data. All modern protocols support both: HTTP and HTTPS (encrypted).

P.S.

Remember that WebSockets generally have a very different approach of logic for networking, more like real-time games had all this time, and not like http.

Short-polling vs Long-polling for real time web applications?

• Short polling (a.k.a. AJAX based timer):

  Pros: simpler, not server consuming (if the time between requests is long).
  
  Cons: bad if you need to be notified WHEN the server event happens with no delay.
  Example (ItsNat based)

• Long polling (a.k.a. Comet based on XHR)

  Pros: you are notified WHEN the server event happens with no delay.
  Cons: more complex and more server resources used.
  Example (ItsNat based)

What are Long-Polling, Websockets, Server-Sent Events (SSE) and Comet?

In the examples below the client is the browser and the server is the webserver hosting the website.

Before you can understand these technologies, you have to understand classic HTTP web traffic first.

Regular HTTP:

1. A client requests a webpage from a server.
2. The server calculates the response
3. The server sends the response to the client.

Ajax Polling:

1. A client requests a webpage from a server using regular HTTP (see HTTP above).
2. The client receives the requested webpage and executes the JavaScript on the page which requests a file from the server at regular intervals (e.g. 0.5 seconds).
3. The server calculates each response and sends it back, just like normal HTTP traffic.

Ajax Long-Polling:

1. A client requests a webpage from a server using regular HTTP (see HTTP above).
2. The client receives the requested webpage and executes the JavaScript on the page which requests a file from the server.
3. The server does not immediately respond with the requested information but waits until there's new information available.
4. When there's new information available, the server responds with the new information.
5. The client receives the new information and immediately sends another request to the server, re-starting the process.

HTML5 Server Sent Events (SSE) / EventSource:

1. A client requests a webpage from a server using regular HTTP (see HTTP above).
2. The client receives the requested webpage and executes the JavaScript on the page which opens a connection to the server.

3. The server sends an event to the client when there's new information available.

   • Real-time traffic from server to client, mostly that's what you'll need
   • You'll want to use a server that has an event loop
   • Connections with servers from other domains are only possible with correct CORS settings
   • If you want to read more, I found these very useful: (article), (article), (article), (tutorial).

HTML5 Websockets:

1. A client requests a webpage from a server using regular http (see HTTP above).
2. The client receives the requested webpage and executes the JavaScript on the page which opens a connection with the server.

3. The server and the client can now send each other messages when new data (on either side) is available.

   • Real-time traffic from the server to the client and from the client to the server
   • You'll want to use a server that has an event loop
   • With WebSockets it is possible to connect with a server from another domain.
   • It is also possible to use a third party hosted websocket server, for example Pusher or others. This way you'll only have to implement the client side, which is very easy!
   • If you want to read more, I found these very useful: (article), (article) (tutorial).

Comet:

Comet is a collection of techniques prior to HTML5 which use streaming and long-polling to achieve real time applications. Read more on wikipedia or this article.

---

Now, which one of them should I use for a realtime app (that I need to
code). I have been hearing a lot about websockets (with socket.io [a
node.js library]) but why not PHP ?

You can use PHP with WebSockets, check out Ratchet.

Polling vs long-polling

polling: hitting a url from a client at some interval

long polling: hitting the url from a client and having the server hold the connection for a period of time, in this way the server can return the connection at the moment when it has information for the client

Not all ajax is long polling. Long polling is best achieved using a framework like cometd. (http://www.cometd.org)

Why use AJAX when WebSockets is available?

WebSockets isn't intended to replace AJAX and is not strictly even a replacement for Comet/long-poll (although there are many cases where this makes sense).

The purpose of WebSockets is to provide a low-latency, bi-directional, full-duplex and long-running connection between a browser and server. WebSockets opens up new application domains to browser applications that were not really possible using HTTP and AJAX (interactive games, dynamic media streams, bridging to existing network protocols, etc).

However, there is certainly an overlap in purpose between WebSockets and AJAX/Comet. For example, when the browser wants to be notified of server events (i.e. push) then Comet techniques and WebSockets are certainly both viable options. If your application needs low-latency push events then this would be a factor in favor of WebSockets. On the other hand, if you need to co-exist with existing frameworks and deployed technologies (OAuth, RESTful APIs, proxies, load balancers) then this would be a factor in favor of Comet techniques (for now).

If you don't need the specific benefits that WebSockets provides, then it's probably a better idea to stick with existing techniques like AJAX and Comet because this allows you to re-use and integrate with a huge existing ecosystem of tools, technologies, security mechanisms, knowledge bases (i.e. far more people on stackoverflow know HTTP/Ajax/Comet than WebSockets), etc.

On the other hand, if you are creating a new application that just doesn't work well within the latency and connection constraints of HTTP/Ajax/Comet, then consider using WebSockets.

Also, some answers indicate that one of the downsides of WebSockets is limited/mixed server and browser support. Let me just diffuse that a bit. While iOS (iPhone, iPad) still supports the older protocol (Hixie) most WebSockets servers support both Hixie and the HyBi/IETF 6455 version. Most other platforms (if they don't already have built-in support) can get WebSockets support via web-socket-js (Flash based polyfill). This covers the vast majority of web users. Also, if you are using Node for the server backend, then consider using Socket.IO which includes web-socket-js as a fallback and if even that is not available (or disabled) then it will fall back to using whatever Comet technique is available for the given browser.

Update: iOS 6 now supports the current HyBi/IETF 6455 standard.

Websocket or Long Polling (using AJAX) to detect Changes in Database using PHP

Here's the best comparison I've seen regarding long polling and the WebSocket API:

http://www.websocket.org/quantum.html

As the above article states, the WebSocket API is far superior to long polling (or any other pseudo-bidirectional communication), but the one downside is that browser support still isn't quite there (IE finally started supporting the WebSocket API in IE10).

As such, if you're looking for a full-on bidirectional communication solution, use the WebSocket API when it's available and fall back to Ajax long polling or whatever comet method you prefer when it's not.

To answer your questions, if you're only making an occasional server-side/DB query (with the term "occasional" being relative and subject to testing on your system), then simple Ajax requests should be fine. However, if you're hammering the server with requests every 10 seconds or less, then using the WebSocket API is definitely ideal.

To answer your last question, SSL is 100% available with the WebSocket API. Simply use the wss protocol instead of the standard ws protocol, and you're there.

---

Related Topics