Un server è un loop infinito in esecuzione come processo in background?

Question

Un server è essenzialmente un processo in background che esegue un ciclo infinito in ascolto su una porta? Ad esempio:

while(1){ 
    command = read(127.0.0.1:xxxx); 
    if(command){ 
     execute(command); 
    } 
} 

Quando dico server, ovviamente non mi riferisco a un server fisico (computer). Mi riferisco a un server MySQL, o Apache, ecc.

Divulgazione completa - Non ho avuto il tempo di filtrare qualsiasi codice sorgente. Esempi di codice reali sarebbero fantastici!

Answer 1

Questo è più o meno il software server in genere.

Di solito diventa più complicato perché il loop infinito "solo" accetta la connessione e ogni connessione può spesso gestire più "comandi" (o qualunque cosa vengano chiamati nel protocollo utilizzato), ma l'idea di base è all'incirca questa.

Answer 2

In una questione di parlare, sì. Un server è semplicemente qualcosa che "loop per sempre" e serve. Tuttavia, tipicamente, i "demoni" fanno cose come STDOUT e STDERR aperti su handle di file o/dev/null insieme a doppi fork, tra le altre cose. Il tuo codice è un "server" molto semplicistico in un certo senso.

Answer 3

Esistono tre tipi di "server": biforcazione, threading e thread singolo (non bloccante). Tutti in genere fanno il giro come si mostra, la differenza è ciò che accade quando c'è qualcosa da servire.

Un servizio di forking è proprio questo. Fork() viene invocato per ogni richiesta creando un nuovo processo figlio che gestisce la richiesta, quindi esce (o rimane attivo, per gestire richieste successive, a seconda della progettazione).

Un servizio di threading è come un servizio di forking, ma invece di un processo completamente nuovo, viene creata una nuova stringa per servire la richiesta. Come i fork, a volte i thread rimangono in attesa per gestire le richieste successive. La differenza di prestazioni e ingombro è semplicemente la differenza tra fili e forche. A seconda dell'uso della memoria che è non che serve un client (e incline a cambiare), di solito è meglio non clonare l'intero spazio degli indirizzi. L'unica complessità aggiunta qui è la sincronizzazione.

Un singolo server (noto anche come thread singolo) esegue il fork solo una volta per il demone. Non genererà nuovi thread, non genererà i processi figli. Continuerà a eseguire il polling() del socket per scoprire quando il descrittore di file è pronto a ricevere dati o se i dati disponibili per essere elaborati. I dati per ciascuna connessione sono mantenuti nella propria struttura, identificati da vari stati (scrittura, attesa di ACK, lettura, chiusura, ecc.). Questo può essere un design estremamente efficiente, se fatto correttamente. Invece di bloccare più thread figlio o thread mentre si attende di lavorare, si dispone di un singolo processo e di richieste di manutenzione del ciclo eventi non appena sono pronti.

Esistono casi in cui i servizi a thread singolo generano più thread, tuttavia i thread aggiuntivi non funzionano per soddisfare le richieste in arrivo, si potrebbe (ad esempio) impostare un socket locale in un thread che consente a un amministratore di ottenere uno stato di tutte le connessioni.

Un po 'di google per server HTTP non bloccanti produrrà alcuni interessanti server Web laminati a mano scritti come sfide del codice golf.

In breve, la differenza è ciò che accade una volta che si entra nel ciclo infinito, non solo il ciclo infinito :)