15.3.4 Un server daytime concorrente

Come accennato anche in sez. 3.1 una delle modalità più comuni di funzionamento da parte dei server è quella di usare la funzione fork per creare, ad ogni richiesta da parte di un client, un processo figlio che si incarichi della gestione della comunicazione. Si è allora riscritto il server daytime dell'esempio precedente in forma concorrente, inserendo anche una opzione per la stampa degli indirizzi delle connessioni ricevute.

In fig. 15.10 è mostrato un estratto del codice, in cui si sono tralasciati il trattamento delle opzioni e le parti rimaste invariate rispetto al precedente esempio (cioè tutta la parte riguardante l'apertura passiva del socket). Al solito il sorgente completo del server, nel file TCP_cunc_daytimed.c, è allegato insieme ai sorgenti degli altri esempi.

01: #include <sys/types.h>   /* predefined types */ 
02: #include <unistd.h>      /* include unix standard library */ 
03: #include <arpa/inet.h>   /* IP addresses conversion utililites */ 
04: #include <sys/socket.h>  /* socket library */ 
05: #include <stdio.h>       /* include standard I/O library */ 
06: #include <time.h> 
07:  
08: int main(int argc, char *argv[]) 
09: { 
10:     int list_fd, conn_fd; 
11:     int i; 
12:     struct sockaddr_in serv_add, client; 
13:     char buffer[MAXLINE]; 
14:     socklen_t len; 
15:     time_t timeval; 
16:     pid_t pid; 
17:     int logging=0; 
18:      ... 
19:     /* write daytime to client */ 
20:     while (1) { 
21:         len = sizeof(client); 
22:         if ( (conn_fd = accept(list_fd, (struct sockaddr *)&client, &len))  
23:              <0 ) { 
24:             perror("accept error"); 
25:             exit(-1); 
26:         } 
27:         /* fork to handle connection */ 
28:         if ( (pid = fork()) < 0 ){ 
29:             perror("fork error"); 
30:             exit(-1); 
31:         } 
32:         if (pid == 0) {                 /* child */ 
33:             close(list_fd); 
34:             timeval = time(NULL); 
35:             snprintf(buffer, sizeof(buffer), "%.24s\r\n", ctime(&timeval)); 
36:             if ( (write(conn_fd, buffer, strlen(buffer))) < 0 ) { 
37:                 perror("write error"); 
38:                 exit(-1); 
39:             } 
40:             if (logging) { 
41:                 inet_ntop(AF_INET, &client.sin_addr, buffer, sizeof(buffer)); 
42:                 printf("Request from host %s, port %d\n", buffer, 
43:                        ntohs(client.sin_port)); 
44:             } 
45:             close(conn_fd); 
46:             exit(0); 
47:         } else {                        /* parent */ 
48:             close(conn_fd); 
49:         } 
50:     } 
51:     /* normal exit, never reached */ 
52:     exit(0); 
53: } 

Stavolta (21–26) la funzione accept è chiamata fornendo una struttura di indirizzi in cui saranno ritornati l'indirizzo IP e la porta da cui il client effettua la connessione, che in un secondo tempo, (40–44), se il logging è abilitato, stamperemo sullo standard output.

Quando accept ritorna il server chiama la funzione fork (27–31) per creare il processo figlio che effettuerà (32–46) tutte le operazioni relative a quella connessione, mentre il padre proseguirà l'esecuzione del ciclo principale in attesa di ulteriori connessioni.

Si noti come il figlio operi solo sul socket connesso, chiudendo immediatamente (33) il socket list_fd; mentre il padre continua ad operare solo sul socket in ascolto chiudendo (48) conn_fd al ritorno dalla fork. Per quanto abbiamo detto in sez. 15.2.6 nessuna delle due chiamate a close causa l'innesco della sequenza di chiusura perché il numero di riferimenti al file descriptor non si è annullato.

Infatti subito dopo la creazione del socket list_fd ha una referenza, e lo stesso vale per conn_fd dopo il ritorno di accept, ma dopo la fork i descrittori vengono duplicati nel padre e nel figlio per cui entrambi i socket si trovano con due referenze. Questo fa si che quando il padre chiude sock_fd esso resta con una referenza da parte del figlio, e sarà definitivamente chiuso solo quando quest'ultimo, dopo aver completato le sue operazioni, chiamerà (45) la funzione close.

In realtà per il figlio non sarebbe necessaria nessuna chiamata a close, in quanto con la exit finale (45) tutti i file descriptor, quindi anche quelli associati ai socket, vengono automaticamente chiusi. Tuttavia si è preferito effettuare esplicitamente le chiusure per avere una maggiore chiarezza del codice, e per evitare eventuali errori, prevenendo ad esempio un uso involontario del listening descriptor.

Si noti invece come sia essenziale che il padre chiuda ogni volta il socket connesso dopo la fork; se così non fosse nessuno di questi socket sarebbe effettivamente chiuso dato che alla chiusura da parte del figlio resterebbe ancora un riferimento nel padre. Si avrebbero così due effetti: il padre potrebbe esaurire i descrittori disponibili (che sono un numero limitato per ogni processo) e soprattutto nessuna delle connessioni con i client verrebbe chiusa.

Come per ogni server iterativo il lavoro di risposta viene eseguito interamente dal processo figlio. Questo si incarica (34) di chiamare time per leggere il tempo corrente, e di stamparlo (35) sulla stringa contenuta in buffer con l'uso di snprintf e ctime. Poi la stringa viene scritta (36–39) sul socket, controllando che non ci siano errori. Anche in questo caso si è evitato il ricorso a FullWrite in quanto la stringa è estremamente breve e verrà senz'altro scritta in un singolo segmento.

Inoltre nel caso sia stato abilitato il logging delle connessioni, si provvede anche (40–43) a stampare sullo standard output l'indirizzo e la porta da cui il client ha effettuato la connessione, usando i valori contenuti nelle strutture restituite da accept, eseguendo le opportune conversioni con inet_ntop e atohs.

Ancora una volta l'esempio è estremamente semplificato, si noti come di nuovo non si sia gestita né la terminazione del processo né il suo uso come demone, che tra l'altro sarebbe stato incompatibile con l'uso della opzione di logging che stampa gli indirizzi delle connessioni sullo standard output. Un altro aspetto tralasciato è la gestione della terminazione dei processi figli, torneremo su questo più avanti quando tratteremo alcuni esempi di server più complessi.