Sign in to follow this  
Rickert

Difference between synchronous (proactor pattern) and synchronous model in web server

Recommended Posts

In synchronous model, when a client connects to the server, both the client and server have to sync with each other to finish some operations.

Meanwhile, the asynchronous model allows client and server to work separated and independently. The client sends a request to establish a connection and do something. While the server is processing the request, the client can do something else. Upon completion of an operation, the completion event is placed onto a queue in an Event Demultiplexer, waiting for a Proactor (such as HTTP Handler) to send the request back and invoke a Completion Handler (on the client). The terms are used as in boost::asio document [url="http://www.boost.org/doc/libs/1_47_0/doc/html/boost_asio/overview/core/async.html"]The Proactor Design Pattern: Concurrency Without Threads[/url].

By working this way, the asynchronous model can accepts simultaneous connections without having to create a thread per connection, thus improve overall performance. In order to achieve the same effect as asynchronous model, the first model (synchronous) must be multi-threaded. For more detail, refer to: [url="http://www.google.com/url?sa=t&source=web&cd=1&sqi=2&ved=0CBsQFjAA&url=http://www.cs.wustl.edu/%7Eschmidt/PDF/proactor.pdf&rct=j&q=proactor%20pattern&ei=iE6MTredOuiViQfmv5XmBw&usg=AFQjCNFoNeWioIF2nqgsmIsjIi403tXOhQ&sig2=vrccRX1YLUI_nDv0addKcw&cad=rja"]Proactor Pattern[/url] (I actually learn proactor pattern which is used to asynchronous model from that document. In here it has description on a typical synchronous I/O web server).

Is my understanding on the subject correct? If so, which means the asynchronous server can accepts request and return results asynchronously (the first connection request the service on web server does not need to be the first to reply to)? In essence, asynchronous model does not use threading (or threading is used in individual components, such as in the Proactor, Asynchronous Event Multiplexer (boost::asio document) component, not by creating an entire client-server application stack, which is describe in the multi-threaded model in Proactor Pattern document, section 2.2 - [b]Common Traps and Pitfalls of Conventional Concurrency Models[/b]).

Share this post


Link to post
Share on other sites
[quote name='Rickert' timestamp='1317877539' post='4869664']
In synchronous model, when a client connects to the server, both the client and server have to sync with each other to finish some operations.

Meanwhile, the asynchronous model allows client and server to work separated and independently. The client sends a request to establish a connection and do something. While the server is processing the request, the client can do something else. Upon completion of an operation, the completion event is placed onto a queue in an Event Demultiplexer, waiting for a Proactor (such as HTTP Handler) to send the request back and invoke a Completion Handler (on the client). The terms are used as in boost::asio document [url="http://www.boost.org/doc/libs/1_47_0/doc/html/boost_asio/overview/core/async.html"]The Proactor Design Pattern: Concurrency Without Threads[/url].

By working this way, the asynchronous model can accepts simultaneous connections without having to create a thread per connection, thus improve overall performance. In order to achieve the same effect as asynchronous model, the first model (synchronous) must be multi-threaded. For more detail, refer to: [url="http://www.google.com/url?sa=t&source=web&cd=1&sqi=2&ved=0CBsQFjAA&url=http://www.cs.wustl.edu/%7Eschmidt/PDF/proactor.pdf&rct=j&q=proactor%20pattern&ei=iE6MTredOuiViQfmv5XmBw&usg=AFQjCNFoNeWioIF2nqgsmIsjIi403tXOhQ&sig2=vrccRX1YLUI_nDv0addKcw&cad=rja"]Proactor Pattern[/url] (I actually learn proactor pattern which is used to asynchronous model from that document. In here it has description on a typical synchronous I/O web server).

Is my understanding on the subject correct? If so, which means the asynchronous server can accepts request and return results asynchronously (the first connection request the service on web server does not need to be the first to reply to)? In essence, asynchronous model does not use threading (or threading is used in individual components, such as in the Proactor, Asynchronous Event Multiplexer (boost::asio document) component, not by creating an entire client-server application stack, which is describe in the multi-threaded model in Proactor Pattern document, section 2.2 - [b]Common Traps and Pitfalls of Conventional Concurrency Models[/b]

[/quote]

It looks like you just copied most of that out of a textbook or technical source, but basically you have got it.

You can have a system that creates a huge process, does a tiny bit of work, and then just sits around waiting for more work to hopefully come some day.

Or you can have a system that gets a request, handles it quickly, and moves on.


It is a sad and too-common mistake for beginners to do the former, not the latter. Such a system does not scale well and will quickly collapse under its own weight as it grows.

Share this post


Link to post
Share on other sites
[quote name='Rickert' timestamp='1317877539' post='4869664']
In synchronous model, when a client connects to the server, both the client and server have to sync with each other to finish some operations.
[/quote]

Synchronous or asynchronous from whose point of view?

When something is "synchronous," then there is a thread of execution that is currently not executing, because it is waiting for an answer of some sort. A HTTP client library may be synchronous, if it works like the "wget" or "curl" command-line programs to retrieve a web page. Send off the URL, wait until the answer is back, return to the client. This is "synchronous" from the point of view of the client.

A server can be "synchronous" or "asynchronous" from the point of view of the request dispatcher. In a synchronous model, a request comes in on a socket, and the process that serves the request goes ahead and runs synchronous/blocking code, and when it's done, the call flow returns to the request dispatcher and writes out the result. In an asynchronous model, some worker gets told that there is work to do, and it can start doing the work, or arrange for other threads to do the work. When the work is done, some message is sent back to the request dispatcher, letting it know that the request is complete.

You can mix and match synchronous clients and servers freely, because the protocol in question is defined only in terms of bytes on the wire, and as long as the right bytes come in the right order on the wire, how the program was written that generates those bytes is of less importance.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this