To share , learn and express my views. (mostly technical)
Methods for asynchronous communication over HTTP
This post was long overdue….was in my draft folder for almost an year now…
Following my post on WebSockets availability in Chrome, I looked around to see what are the options for asynchronous communication over HTTP without WebSockets. Below, I list the available approaches prior to WebSockets and I will also discuss the pros and cons of these approaches.
We know that HTTP is a synchronous request/response application protocol and in which a client always initiates a request and the server responds to the request; the server never initiates a request to the client. This communication pattern limits HTTP applications to synchronous “pull” only interaction pattern. However, there are several approaches that emulate asynchronous communication over a synchronous communication channel. I briefly explain each method with their pros and cons below:
Polling ( also called Pull Technology)
Polling requires the client to send request to the server at regular intervals to check if there are any updates. Server events can be queued and delivered to the client on each request from the client emulating server initiated communication. The polling interval can be fixed and determined based on the application requirement or the server can indicate polling interval in its responses.
- Simplifies server implementation by not requiring the server to maintain a list of subscribers and by shifting the responsibility of guaranteed delivery to consumers.
- Stateless interaction
- True real time communication not possible and is bound to the poll interval.
- Uses up server resources unnecessarily
- Will have to strike a balance between shorter and longer poll intervals to improve efficiency
- Increased network traffic (can be reduced by using conditional GET
This is a variation of the polling approach in which a client sends a request to the server and the server sends a response only if there is information to be sent in the response. If the server determines the requested resource is not changed, it holds on to the request until the resource is changed or if the specified timeout expires. When the server sends out the response either due to updates in the requested resource or due to timeout, the client issues another request and whole cycle repeats i.e. the server always has a pending request from the client.
- Better real time communication compared to normal polling because the information is sent as soon as it is available.
- Open HTTP connections consume system resources.
- Each request will a require thread that blocks the requests until data is available or till timeout. If there are multiple requests, this will result in large number of threads blocking for data.
- Server side support for asynchronous request processing (Asynchronous I/O) is required for scalability.
- No standard mechanism available. Each environment has its own mechanism to handle long polling.
HTTP streaming is similar to long polling except that the connection is never closed even after the data is pushed to the client by the server. In this approach, a client sends a request to the server and the server responds to the request by sending data back to the client. However, after the data is sent, the server does not close the connection but instead keeps the connection open and pushes data to the client whenever available over the same connection.
- Allows sending multiple data transmission over single connection and results in fewer requests to the server.
- No connection over head.
- Real time updates possible.
- No standard mechanism available. Each environment has its own mechanism to handle streaming.
- Might not work through proxies/firewalls
- Might result in large number of open connections when there are multiple requests.
WebHook provides a HTTP callback via HTTP POST when an event occurs. A Web application implementing WebHook will POST a message to a specified URI as an event notification. It also allows clients to register custom URIs with Web application which then POST messages to these URIs to indicate state changes. The notification URI should point to HTTP server.
- Provides near real time updates.
- Standardization attempts via WebHook and PubHubSubHub initiatives
- Polling is eliminated.
- Fully asynchronous
- Might not work through proxies/firewalls
- Requires the receiver to host a HTTP server.