Request-response vs. message pushing

Some architectures and protocols were designed for request-response type of communication. In HTTP, the client asks the server to GET, POST, DELETE, HEAD etc. something, and the server responds (or fails to respond). In POP3, the server role is limited to answer the requests, nothing more.

Some others are designed in a way that the client and the server are communicating together, which enables scenarios which are hardly possible in a request-response model. IMAP, for example, has an advantage over POP3 to allow the new messages to be delivered immediately to the client. To achieve the same nearly-immediate behavior with POP3, the only thing you can do is to query the server for new emails once per second, which obviously raises performance and bandwidth usage issues.

Message pushing in practice

In general, pushing information from server to client may be totally acceptable in some cases. You quoted yourself an example of a type of products where this is a common practice: multiplayer games.

In a web applications, it is unusual to see the information to be sent by the server to the client for several reasons:

• In many cases, you don’t need such feature in a web application. For example, why would MSDN or Google Images start to push something to my browser? Or why would TheDailyWTF change its content on the fly while you’re browsing it?

• For a while, it was impossible to do it without using Java applets or similar non-HTML components, making it very complicate to implement in a website. If you were creating a chat application, using a Java applet wasn’t probably too difficult, but for any other web app, it was an overkill. For example, I hardly imagine eBay creating a Silverlight app which would establish a two-way communication with the server in order to update the bids in real time.

Some people came with alternative solutions, but they had their own drawbacks (performance and bandwidth usage). For example, it was not unusual to see some bulletin boards making regular AJAX requests (every ten seconds for example) to see if something changed.

Today, things start to change with HTML 5 and WebSockets. Stack Exchange is an excellent example of a proper use of them: actually, when you see the notifications about new comments or answers or when you see the up and down votes in real time, it’s done with WebSockets.

With WebSockets, you may imagine other valid uses of two-ways communication in browsers:

• Real time information. Example: for large cities, Google Maps has Traffic feature. What about updating this information in real time, or notifying the drivers immediately when an road accident causes traffic jam?

• Social interactions. Example: when posing a comment on a blog, what about the ability to see the comments of other people immediately after they are posted? Another example: what if, in a bug tracking system, I can see immediately the newly created bug reports?

• Cases where immediate response is required. Example: a monitoring panel used by a system administrator may be written in HTML and with WebSockets, it may inform the sysadmin immediately if a server is down.

• etc.

I dont think it’s wrong. E.g. The company I am with offers a client-server version control system, which pushes a message of in-advance notice when scheduled maintenance is up.