2

I would to make a simple multi process (not thread) server. I've seen the iterative example in which it handles one request at a time. Instead I need to handle more requests(more on less 10) at the same time. In the classic c and c++ examples, I've seen that the server is designed like the following:

int listensd, connsd; // listening socket and conection socket
pid_t pid;            //process id
listensd=socket(....); 
bind(listensd,...);
listen(listensd,...);
for(;;)
{

  connsd=accept(listensd,...);
  if((pid=fork())==0)  //child process
  {
        close(listensd);  //close the listen socket
        do_it(connsd);    //serve the request
        close(connsd);    //close the connection socket
        exit(0); 
   }
close(connsd);     //the parent closes the connection socket
}

Is it possible to do something like that with boost? I really don't know how obtain the two different socket, because in boost all the function (listen, bind, accept, etc.) return void.

marco
  • 21
  • 3
  • Why do you feel you need a process per connection? Such a design simply does not scale, and really isn't in the spirit of asynchronous design patterns promoted by Boost.Asio. – Sam Miller Mar 01 '11 at 15:12
  • 1
    Quite sure you can. Have a look at one of the multithreaded examples and where it would normally kick off another thread, you should be able to fork instead. – hookenz Mar 01 '11 at 15:23
  • What part of this has to do with `boost::asio`? AFAIK, the posted code is all POSIX! – André Caron Mar 01 '11 at 19:01
  • @Matt, are you so kind to tell me at which example do you refer and where I have to put the fork() instruction? thanks... Andrè..the code posted is obviously POSIX..the goal of my question is in the last two lines...then if it is possible to obtain with the Boost asio library the same behaviour that I obtain through the code I've posted... –  Mar 01 '11 at 19:22

1 Answers1

0

Yes, it's possible to use Boost.Asio to fork a process for each connection. See the BSD Socket API Boost.Asio documentation for the mappings for bind, listen, accept into the relevant Boost.Asio types.

Though, as I pointed out in my comment, I don't feel this design scales well at all. You're better off learning asynchronous design patterns and using the real strengths of the Boost.Asio library. For more information, see the C10K problem.

Sam Miller
  • 23,808
  • 4
  • 67
  • 87