What is a server asynchronous response?

Question

I'm reading about real-time web, and I've noticed a sentence allow Django to do async responses. For what I understood till now was that it is possible to achieve parallelism on the client by issuing multiple Http requests form the same side using Ajax, but for the server, those are just separated requests each handled in ins own threas.

How I see it working:

1. Client sends two requests
2. Server receives them and solves them each in its own thread, and returns to client

What is a conceptual example of a async server?

Answer 1

HTTP is a blocking, synchronous protocol. This means that the client has to wait for a response from the server before it can continue. The server blocks the clients from doing anything; because the client has to wait for the response to come through. Once the response is received by the browser, the connection is dropped and then another connection is opened and the process repeats till all the elements of the page have been fetched to be displayed.

This is the state of the web, and the nature of the HTTP protocol.

Ajax simply creates a background process that does what the browser would have done - it is still blocking, but the end effect is that the user can still interact with the client. The browser is displaying something and is not effectively "blocked".

The "realtime" web allows you to have an open socket that is non-blocking, asynchronous. Asynchronous means that you don't have to wait for the response to come back - the client isn't blocked. You can send off multiple requests, and then when the server is done with them, it will respond back. You don't have to "wait".

Many things you use everyday are asynchronous:

1. Any chatting application - like IRC, facebook messenger, whatapp, etc.
2. A telephone conversation with a really chatty friend (typically, you would wait to hear the other person's response, but some people just talk and talk...).
3. Anything that is streaming, like YouTube.

Think of it as simply "one side doesn't have to wait to start transmitting again".

In web, realtime is enabled by getting around the limitations of HTTP. This is where WebSockets and Server sent events (SES) come in.

The first is a standard way of opening a full-duplex (that is, you can send and receive at the same time) channel over TCP.

The second (SES) is still being standardized as part of HTML5 but it allows the server to push notifications to the client instead of the client having to poll the server for events. So instead of you sending a request to check for updates, the server will tell you when there is an update - like "don't call me, I'll call you".

Answer 2

Here is a conceptual diagram how it works, you can see that the server-side (HTTP Server) is answering for async requests from a DIV, so each answer can be seen as an async answer.

Due the answers come from a server which is able to serve in a async way, then the server can be considerate a async server.

BTW, the article/diagram comes from an .NET scenary, AJAX behavior is generic and that is the way how it works on a general view.