# [c/c++] Multiplie sockets with fork



## Alt (Feb 12, 2010)

Im writing a small fastcgi app and i want to make it work as many listeners like this:

```
# sockstat -l
USER     COMMAND    PID   FD PROTO  LOCAL ADDRESS         FOREIGN ADDRESS
alt      fcgi-serve 93657 3  stream /tmp/fcgi-server.sock
alt      fcgi-serve 93656 3  stream /tmp/fcgi-server.sock
alt      fcgi-serve 93655 3  stream /tmp/fcgi-server.sock
alt      fcgi-serve 93653 3  stream /tmp/fcgi-server.sock
```
It listens as 4 workers, but i wanna it work as 5 workers, so i do this like:

```
while(1) {
        while( child_list.size() < numforks ) {
            pid_t pid = fork();
            if( pid == -1 ) {
                // error
                cout << "Fork fail" << endl;
                exit(EXIT_FAILURE);
            }else if( pid == 0 ) {
                // child
                worker_pid = getpid();
                worker_served_count = 0;
                return 0;
            } else {
                cout << "Child "<< pid << " forked"<<endl;
                child_list.push_back(pid);
            }
        }
   sleep(1);
}

// ...some code here...

// Open socket
int listen_socket = FCGX_OpenSocket(sock.c_str(), queue_len);
```
By the plan, it must fork 5 times(numforks=5) and stay manage this workers. So it should be 6 processes, 5 of them(workers) listening.. Each worker must open socket on same unix socket path, listening queries at same time, but....

```
> ./fcgi-server
fork 5 times
Child 91862 forked
Child 91863 forked
Child 91864 forked
Child 91865 forked
Child 91866 forked
bind/listen: Address already in use
```
This "Address already in use" shows sometimes, so i see only 4 listeners in `sockstat -l`.. 
Sometimes it gives only 3 listeners (2 times "already in use") or 5 listeners (all ok). 
Took algorythm from FCGI:rocManager perl module, but cant get it to work correctly...
I guess there is a bug somewhere, it should not work time-to-time =) Cant find whats problem.. Thanks for help


----------



## redbrain (Feb 12, 2010)

Just want to ask a few questions, I haven't write cgi code before but do you want to basically have a C program to have a threshold value of listener sockets who fork(); and do something and listen again?

I guess you want to fork to give it the style of apache/other stuff who start many separate processes.


----------



## Alt (Feb 12, 2010)

Yes i want many separate processes, anyone connects socket must connect any free worker, which then serve request.. 1 process still work without socket, managing this 'workers' (signals, keeping their count, etc)
Above model works, but problem is sometimes i get "bind/listen: Address already in use", so i get less worker processes=(

UPD: Solved. Must create socket before forking xD Thanks for help


----------



## expl (Feb 12, 2010)

Well I just want to add that having CGI program with multiple forks combined with bind calls is a recipe for disaster on bigger scale. It would be a possible target for a DoS attack making it much more easier to kill your machine. I'd suggest a different mechanism with a custom threaded daemon handling sockets and CGI program acting as a client between web controls and daemon.


----------



## Alt (Feb 13, 2010)

Its not http daemon, its not cgi program =) Its fastcgi daemon =) Of course, this would not interact with enduser, www/nginx will xD


----------



## expl (Feb 13, 2010)

Alt said:
			
		

> Its not http daemon, its not cgi program =) Its fastcgi daemon =) Of course, this would not interact with enduser, www/nginx will xD



What do you mean its not CGI program? "fastCGI" is an extension/API for CGI protocol making a program using it a CGI program and it does not matter if you use apache or nginx or what ever HTTPd its still a bad idea to do forks in web apps.


----------



## Alt (Feb 13, 2010)

Maybe its name is somehow confusing =)
CGI-program is a program that runs from disk on every request.
FastCGI-program is a daemon who answers to requests on unix or network socket.
Suppose is same, mechanics is absolutely different.


----------

