modo migliore per scrivere un demone linux [chiuso]

Question

Per lavoro devo scrivere un demone tcp per rispondere al nostro software client e mi chiedevo se qualcuno avesse qualche consiglio sul modo migliore per farlo.

Dovrei forkare per ogni nuova connessione come normalmente userei i thread?

Answer 1

Dipende dalla tua applicazione. Thread e fork possono essere entrambi approcci perfettamente validi, nonché la terza opzione di un modello basato su eventi a thread singolo. Se puoi spiegare un po 'di più esattamente quello che stai scrivendo, sarebbe utile dare consigli.

Per quello che vale, ecco alcune linee guida generali:

• Se non si dispone di uno stato condiviso, utilizzare il fork.
• Se si dispone di uno stato condiviso, utilizzare i thread o un sistema basato sugli eventi.
• Se hai bisogno di prestazioni elevate con un numero molto elevato di connessioni, evita il biforcazione poiché ha un sovraccarico maggiore (in particolare l'uso della memoria). Utilizzare invece thread, un loop di eventi o più thread di loop di eventi (in genere uno per CPU).

Generalmente il fork è la più semplice da implementare, poiché puoi essenzialmente ignorare tutte le altre connessioni una volta che hai fork; sottopone il thread più difficile successivo a causa dei requisiti di sincronizzazione aggiuntivi; il circuito degli eventi più difficile a causa della necessità di trasformare l'elaborazione in una macchina a stati; e più thread che eseguono loop di eventi il ??più difficile di tutti (a causa della combinazione di altri fattori).

Answer 2

Suggerirei di fare il fork di connessioni su thread ogni giorno. Il problema con i thread è lo spazio di memoria condiviso e quanto è facile manipolare la memoria di un altro thread. Con i processi a forcella, qualsiasi comunicazione tra i processi deve essere intenzionalmente effettuata dall'utente.

Ho appena cercato e trovato questa risposta SO: Qual è lo scopo di fork? . Ovviamente conosci la risposta a questo, ma la risposta n. 1 in quella discussione ha buoni punti sui vantaggi di fork ().

Answer 3

A parte la buona risposta di @ hobodave, un altro vantaggio di "quotazione per connessione" è che potresti implementare il tuo server in modo molto semplice, usando inetd o tcpserver o simili: puoi quindi usare input standard e output standard per comunicare con il socket, e don non è necessario eseguire alcuna gestione delle prese di ascolto (ascolto di connessioni, ecc.), ecc.

Answer 4

Un'altra opzione, ovviamente, è pre-forking diverse copie del demone e avere ognuna in vita e continuare a rispondere alle richieste. Tutto dipende dall'applicazione, dal carico previsto e dai requisiti di prestazione, tra le altre cose.

Il modo più semplice e semplice è scrivere un demone basato su inetd; il tuo software può ignorare il fatto che è in esecuzione su una connessione TCP e gestire semplicemente input / output tramite stdin / stdout. Funziona bene nella stragrande maggioranza dei casi.

Answer 5

Se non hai intenzione di essere martellato con molte nuove connessioni al secondo, prendi in considerazione l'esecuzione da inetd. In caso contrario ...

Scarica l'origine OpenSSH. Hanno dedicato molto lavoro alla separazione dei privilegi nel modo giusto, è portatile ed è stato esaminato per motivi di sicurezza più che per qualsiasi altra cosa.

Adattalo alle tue esigenze, probabilmente puoi buttarne via la maggior parte. Rispettare ovviamente il contratto di licenza. Segui le patch future con un buon SCC.

Non preoccuparti delle prestazioni dei processi di fork e thread fino a quando non hai una buona prova che è un vero problema. Apache ha funzionato per anni e anni gestendo i siti più attivi con il semplice modello di processo per client.

Se sei davvero ambizioso, potresti usare una sorta di modello IO asincrono non bloccante. Mi piace Boost.Asio, ma sono molto interessato al C ++.

Assicurati che il tuo codice gestisca correttamente i segnali. HUP per ricaricare la configurazione. TERMINE da arrestare con grazia.

Non provare a scrivere il tuo file di registro. Usa solo syslog o scrivi semplicemente a stderr che può essere reindirizzato a syslog. È una vera seccatura provare a configurare logrotate su server home roll che registrano tutti in modo leggermente diverso.

Answer 6

Se si desidera evitare il threading / il fork tutti insieme, si consiglia di utilizzare tutti gli I / O non bloccanti insieme a libevent . Libevent è abbastanza noto come soluzione ad alte prestazioni per la programmazione guidata dagli eventi.

Answer 7

Guarda ACE (C ++ / Java) . Ha un numero di reattori TCP threaded, di eventi e di fork che soddisfano i tuoi requisiti di comunicazione. Puoi anche esaminare Boost ASIO che fa qualcosa simile