Newsgroup: it.comp.os.linux.development
Titolo: programmi client\server

salve a tutti avrei bisogno di una mano per la realizzazione di un
piccolo programma in c da far girare su linux per la comunicazione tra
processi. Credo di aver già individuato la soluzione più pratica che
credo sia l'uso di code di messaggi ma ho dei problemi con la
realizzazione del'eseguibile se c'è qualcuno che può passarmi delle
informazioni utile può contattarmi qui o sul mio indirizzo e_mail
pac...@google.it
 ciao a tutti e grazie.

Pasqy ha scritto:

Code di messaggi?? Per carita!!!
Per altre forme di IPC potrei aiutarti, ma per quella roba proprio no.
Ma quali sono le peculiarita' che te le fanno preferire? Davvero non
si puo' fare diversamente? Pipe o socketpair per processi parenti,
socket (connectionless o connection oriented) per client/server,
memoria condivisa (ma io preferisco mmap di BSD) per condivisione di
info anche se il processo produttore non e' piu'. Credo che le code di
messaggi potevano anche non essere inventate, per quanto ho letto che
solo con esse e' possibile passare un descrittore di file aperto
(a che servira' poi...)
Se i messaggi devono rimanere disponibili anche quando il produttore
ha chiamato exit() e il consumatore non e' stato ancora avviato si puo'
fare il molti modi comunque, anche creare un processo che conserva
datagrammi, ma in User-space. Perche' caricare il Kernel anche di questo?
Con la memoria condivisa poi ci si guadagna anche in efficienza.
Se ci spieghi lo scenario magari potremmo anche rettificare il protocollo
IPC che stai progettando. Comunque un consiglio (mio e opinabile) e' di
non usare mai, per quanto possibile, le code di messaggi. Al limite e'
meglio un processo proxy per ausilio a IPC tra terzi processi.
Ciao
Roberto.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 processi.
esercizio universitario?  lo dovremmo fare noi?
-- 
Maurizio Loreti                         
http://www.pd.infn.it/~loreti/mlo.html
Dept. of Physics, Univ. of Padova, Italy              ROT13: 
ybe...@cq.vasa.vg

 credo sia l'uso di code di messaggi
ma il buon vecchio socket, no?

Ciao Maurizio, scusami ma credo di non aver capito bene il tuo
messaggio ..... cmq si è un esercizio universitario , magari se hai
delle informazioni utili per me possiamo discuterne ciao e grazie per
il messaggio.

ciao roberto , anche io avevo pensato a socket ma mi hanno dato dei
problemi in quanto ,essendo un esercizio universitario, ci sono delle
specifiche da rispettare cmq la comunicazione e tra più di due
processi in quanto diciamo che c'è un processo richiedente e un
processo servente il quale a sua volta una volta ricevuta la richiesta
dal processo richiedente, genera un figlio con il quale soddisfa le
richieste del processo richiedente. Quindi utilizzando delle socket ne
avrei bisogno almeno di tre diverse .... cmq ti ringrazio ci sentiamo
presto ciao.

Pasqy ha scritto:

Per quello che hai esposto direi che i socket sono i piu' indicati.
Oltre la scalabilita' (il client e il serves possono, usando socket INET,
stare su macchine separate) e' proprio un classico. Non hai bisogno di
3 socket: il server si mette in ascolto su in socket (LISTEN) con bind()
a una risorsa nota (in dominio UNIX /tmp/miasocket, in INET su una porta
TCP o UDP) e il client lo contatta con connect() su tale risorsa.
Alla connessione entrante il server chiama fork() che tra le altre cose
duplica il socket descriptor per il client. Il figlio chiude il socket in
ascolto e usa quello connesso, il padre viceversa perche' rimane in ascolto
per accettare altre connessioni entranti.
http://www.lilik.it/~mirko/gapil/gapilsu244.html#x635-31700015.4.3
Non ho provato questo codice, ma visto il prestigio che ha questa
pubblicazione ti consiglio di partire da qui, Altrimenti i libri di
Richard Stevens
Ciao
Roberto


 esercizio universitario?  lo dovremmo fare noi?
Ci aiuta a tenere la mente fresca. Non hai nostalgia dei bei tempi passati
all'universitą? :-)
-- 
  Giuseppe "Cowo" Corbelli ~\/~ My software: 
http://cowo.yoda2000.net
    **ANTI-SPAM** -- **Substitute IHATESPAM with cowo to reply by mail**
-<! Evitate di contribuire alla diffusione della musica cattiva; cercate
      anzi di sopprimerla con tutte le vostre forze. - R.Schumann !>-

Se ti aiuta a tenere la mente fresca dammi un indirizzo che ti invio la
specifica... grazie a dopo

Code di messaggi?? Per carita!!!
Io le uso con soddisfazione nella comunicazione tra thread distinti
(parlo di API di Windows, però, non programmazione per Linux) ma sono
interessato a conoscere i motivi di tanto tuo scetticismo...

Andrea Laforgia ha scritto:



Non metto in dubbio che funzionino e neppure che siano veloci visto che
realizzati un kernel-space, la mia scelta di non usarli se non per delle
loro peculiarita' che li rendono insostituibili (e non so' quali siano)
nasce piu' da considerazioni strategiche/filosofiche che probabilmente
non vanno bene per tutti. Provo ad esporre:
Considerazione strategica: Io scrivo solo codice amatoriale, niente di
professionale e quindi mi va di scrivere codice che classifico come
"pregiato". Cerco quindi di non utilizzare, se non indispensabili,
tecnologie poco utilizzate, mal standardizzate, non implementate su
molti sistemi e su cui la maggior parte dei programmatori non ha scommesso.
(e infatti non ho mai utilizzato nemmeno i thread!). La code di messaggi,
in ambiente Unix/POSIX/Linux di solito non sono preferite quindi anche io
per non rendere il mio codice dipendente da tecnologia meno supportata
preferisco altre soluzioni.
Esempio se devo mandare un messaggio ad un processo esistente gli mando
un datagramma tramite socket PF_UNIX DGRAM che sara' sicuramente realizzata
nel modo piu' efficiente possibile per quel sistema, magari anche con la
stessa tecnologia della memoria condivisa o message-queue (dettagli interni
ma si puo' dire che non dovrebbe essere meno efficiente, semmai pari).
Quindi scelgo una tecnica scelta da molti piu' programmatori, scalabile
(un giorno il ricevente potrebbe non essere sulla stessa macchina e
allora usero PF_INET e tutto funzionera') e usante tecnologia piu'
consolidata e debuggata.
Considerazione filosofica: Anche questa opinabile, ma semplicemente non
mi piace che il kernel si prenda questo onere. Diverrebbe come un NEWS
SERVER. Mi ispira molto come sono progettati HURD e QNX, Microkernel e
tutto il resto in userspace. Io metterei anche lo stack TCP/UDP/IP in
userspace!! :)
Quindi se devo lasciare un messaggio per un processo non ancora lanciato
preferisco avvalermi di un processo proxy che lo conservi in una struttura
dati efficiente insieme ad altri per quando qualcuno vi vorra' accedere.
Questa tecnica che sembra masochista (me neanche molto) permette pero'
di inventare protocolli a bizzeffe. Esempio il proxy potrebbe realizzare
comunita' di condivisione di messaggi tramite sistemi di auth basati su
crittografia (o meglio HMAC) e quindi diverrebbe molto piu' impiegabile.
Considera che nessuno mi paga per scrivere codice quindi mi posso
permettere
queste riflessioni. :)
Spero di non aver scritto cose ritenute troppo farneticanti :)
ciao


in ambiente Unix/POSIX/Linux di solito non sono preferite
Per quale motivo?

 Per quale motivo?
Mai studiati i thread! Ho oramai un corredo di porzioni di codice
collaudato basato su fork() + socketpair() + select() sia in C che Perl
che non mi va di cambiare stile. Inoltre non vorrei dover dire a
qualcuno che volesse usare il mio codice "Devi aggiornare il kernel
alla ver 2.6.XX".
Ciao
Roberto


Mai studiati i thread! 
Mi riferivo al perché le code dei messaggi, in mabiente
Unix/POSIX/Linux, come affermi, non sono preferite.

 Unix/POSIX/Linux, come affermi, non sono preferite.
uno che e' perplesso come me l' ho trovato:
http://www.lilik.it/~mirko/gapil/gapilsu196.html#x526-25400012.4.2
e anche Richard Stevens era abbastanza perplesso.


e anche Richard Stevens era abbastanza perplesso.
Continui a dire che tutti sono "perplessi", ma non se ne capisce bene
il motivo (per inciso: S.P. in quell'articolo specifica che i socket
sono più "comodi", quindi deduco che la sua è un genere di
"perplessità" analoga alla tua).  Perché perplessi? per quale ragione
tecnica?

 tecnica?
Per nessuna ragione tecnica.


e se un giorno client e server non saranno sulla stessa macchina?
Il tuo ragionamento è giusto, in linea di massima, ma ci sono
circostanze in cui non è conveniente agire così, per il semplice
motivo che si rischia di sparare alle formiche con un cannone.  
Se per un compito specifico, basta e avanza una soluzione, a volte è
bene usarla, senza porsi troppi problemi su tutte le possibili
prospettive future.  Ovviamente ci vuole buon senso, raggiungere un
compromesso e non avere una visione troppo specifica.
Tutto dipende, poi, da ciò che ci sta sviluppando.  
Capisci che se scrivo un'applicazione multithread, posso pensare che
un giorno diventi multiprocesso, se diventerà multiprocesso allora
potrebbe dividersi tra le macchine.  A quel punto la comunicazione tra
"thread" sarebbe implementata via socket e questo mi starebbe bene, ma
usare da subito i socket per un'applicazione del genere è almeno
inadeguato (alpiù folle ;-). Poi, la scalabilità nei progetti reali è
sempre molto minore rispetto a quella che ci si può attendere.  In
ogni caso, a me è sembrato che tu proponessi una soluzione, perché
alla fine conosci solo quella.  Mi chiedevo il perché criticassi l'uso
della coda dei messaggi ("Code di messaggi?? Per carita!!!", "Credo
che le code di messaggi potevano anche non essere inventate", "Un
consiglio (mio e opinabile) e' di non usare mai, per quanto possibile,
le code di messaggi", ecc...).  Tutto qui.