Newsgroup: it.comp.os.linux.development
Titolo: demon per programma client-server

Salve,
mi sto addentrando sempre più nello sviluppo client-server su TCP.
Ho scritto una piccola applicazione che tramite i socket scambia dati tra un
programma server ed uno client.
Tale comunicazione è, per così dire, "punto-punto", nel senso che non mi
sono preoccupato di eventuali rischieste simultanee da più client.
Ora vorrei approfondire la cosa scrivendo un programma lato server che può
rispondere a richieste multiple e trasformarlo poi in un demon
 analogo, per funzione, a telnetd (tanto per capirci).
Potete indicarmi da dove cominciare a leggere/guardare/copiare/studiare?
Grazie mille
Ioson


In genere un programma del genere e' multi-processo o multi-thread.
Guardati la fork per il multi-processo e le pthread per il multi-thread.
-- 
Salvatore Iovene
http://www.iovene.com/

 ha scritto nel messaggio
news:eskh8a$8h9$3...@tdi.cu.mi.it...


 E con quale principio scelgo tra un caso o l'altro?
Creare processi costa piu' che creare thread.
PS: quota bene.



Scusa se continuo ed approfondisco....
Capisco che in termini di prestazione (in senso lato) creare processi sia
più costoso, ma, mi chiedo se sia più facile da gestire.
Mi spiego:
Quello che ho in mente di fare è una applicazione che risponde a richieste
continue ( ma non insistenti.. al massimo con un ritmo di una ogni 10
secondi )
da vari client. la quantità di dati da scambiare ad ogni richiesta è fissa
(5120bytes) , almeno nella versione iniziale.
Il numero di client può essere al massimo 20 (+o-): quindi, come impegno,
stiamo parlando di un lavoro molto piccolo.
Quello che mi preoccupa di più, non avendo mai scritto una cosa simile, è la
"gestione" di tali connessioni.
Cioè, immagino di avere bisogno di un piccolo "manager" per gestire le
connessioni che mi faccia chiudere i processi che sono rimasti in hang,
che mi faccia vedere che in questo momento ci sono N connessioni da questi
IP eccetera.
Detto ciò, in linea di principio, è il caso di orientarsi verso i tread o i
processi?
Grazie per qualsiasi parere.
Ciao


Beh, l'unica cosa che mi sembra opportuno aggiungere, e' che la
comunicazione inter-thread e' piu' facile (imho), della comunicazione
inter-process. Quindi, lasciando perdere minuscole questioni di
prestazioni, la scelta dipende da se hai bisogno che i thread (o i
processi) condividano della memoria.


C'e` anche da considerare la possibilita` di un programma "event based"
che sfrutta socket asincroni, ma dipende molto dai dati che devi
ritornare - se il programma mette troppo tempo a calcolarli, e` meglio
andare di thread o fork.  Tcl, per esempio, gestisce molto bene questo
genere di programma in poche righe di codice:
proc Cleanup {in out bytes} {
    close $in
    close $out
}
proc RandServ {chan clientaddr clientport} {
    set fl [open /proc/cpuinfo r]
    fconfigure $fl -blocking 0
    fconfigure $chan -blocking 0
    fcopy $fl $chan -command [list Cleanup $fl $chan]
}
socket -server RandServ 8899
vwait forever
Ancora migliore e` il linguaggio erlang perche` contiene uno scheduler
suo, e quindi anche eventi che calcolano risultati non bloccano altri
eventi.
-- 
David N. Welton
- 
http://www.dedasys.com/davidw/
Linux, Open Source Consulting
- 
http://www.dedasys.com/

 
http://www.iovene.com/
Scusa se rispondo soltanto oggi, ma sono stato fuori...
Quando dici "..condividano la memoria.." intendi tra di loro o tra loro ed
il processo di base?
tanto per fare un esempio.. il server telnet (telnetd) usa i thred o i
processi?
Quello che ho in mente č una cosa analoga a telnetd, in cui i processi
"figli" non comunicano tra loro (almeno direttamente) ma solo con il server.
Comunque da come scrivi, mi sembra di capire che la gestione della
condivisione di memoria con i thread sia molto piů complessa di quella con i
processi.
Grazie
Ioson