Re: [boost] Boost Asio on multi processor environment

Hi, Christopher Kohlhoff <chris <at> kohlhoff.com> writes:
On Tue, 24 Apr 2007 17:59:29 +0530, Gaurav.Jain <at>
iflexsolutions.com said:
Hi,
I am designing a server which will going to run on multiprocessor and which will going to provide service to thousand of clients concurrently. I am using boost asio library to do this. I want to know how can I use one io_service object per CPU approach for this?
I'm sure I've outlined this in another email somewhere, but I can't find it right now. Anyway, the basic idea is as follows:
- Create an io_service for each CPU.
- Create an io_service::work object for each io_service to keep it running when it would otherwise have nothing else to do.
- Spawn a thread for each io_service to call io_service::run().
- Create a tcp::acceptor on one of the io_services.
- Create your tcp::socket objects on any of the io_services, using some sort of load balancing scheme to choose the io_service to use (e.g. round robin).
- Ensure that all communication between io_services uses message passing, i.e. use io_service::post().
The core of the work would probably happen in a handle_accept function(), e.g. using the Daytime.3 tutorial program as a starting point:
void start_accept() { // ------> Load balance here <------ tcp_connection::pointer new_connection = tcp_connection::create(choose_io_service());
acceptor_.async_accept(new_connection->socket(), boost::bind(&tcp_server::handle_accept, this, new_connection, asio::placeholders::error)); }
void handle_accept(tcp_connection::pointer new_connection, const asio::error_code& error) { if (!error) { // ------> Use message passing here <------ new_connection->socket().io_service().post( boost::bind(&tcp_connection::start, new_connection));
start_accept(); } }
Cheers, Chris
Thanks for your prompt reply. In your design you are accepting on one io_service and creating a socket on another. I have couple question for you : 1. Can I use same io_service for accepting and socket creation in multiprocessor scenario? If yes, does it have any constraint which I should take into consideration while designing an application? 2. If I have more than one acceptor running and each of them accepting connection on same io_service on which they are created, how should one handle of processing of client's requests? Regards, Gaurav Jain DISCLAIMER: This message contains privileged and confidential information and is intended only for an individual named. If you are not the intended recipient, you should not disseminate, distribute, store, print, copy or deliver this message. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete or contain viruses. The sender, therefore, does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required, please request a hard-copy version.

On Wed, 25 Apr 2007 13:36:52 +0530, Gaurav.Jain@iflexsolutions.com said:
1. Can I use same io_service for accepting and socket creation in multiprocessor scenario?
Yep.
If yes, does it have any constraint which I should take into consideration while designing an application?
No, I don't think so.
2. If I have more than one acceptor running and each of them accepting connection on same io_service on which they are created, how should one handle of processing of client's requests?
Do you mean you will have one acceptor for each io_service, and one io_service for each CPU? If you expect to have about the same amount of work for each type of connection, then you could just handle all per-connection request handling on the same io_service as the acceptor. However, I'm not sure I completely understand what design you're proposing in this second question. Cheers, Chris
participants (2)
-
Christopher Kohlhoff
-
Gaurav.Jain@iflexsolutions.com