Newsgroup: it.comp.os.linux.development
Titolo: socket server: quale libreria consigliate?

Salve NG,
ho un programma scritto in c che si occupa di scambiare dati con i client in
modo asincrono: il client fa una richiesta e il server risponde quando ha i
dati disponibili perche' sono acquisiti tramite la memmoria condivisa con
un altro processo. Nel frattempo il server puo' rispondere ad altri client
per i quali ha gia' le risposte e puo' accettare nuove richieste.
Tuttavia se si collegano piu' di 2-3 client ho qualche casino che non sono
riuscito a sistemare, del tipo che arrivano mezzi comandi mischiati con
quello precedente (invio stringhe), quasi sicuramente un problema di
buffer.
Ci sono librerie di piu' alto livello? Siccome uso gia' le glib pensavo che
ci fosse qualcosa di utile, forse GIOChannel, ma non trovo esempi decenti.
Ogni suggeriento e' gradito.
Grazie, Nicola.
-- 
chi va pian va san e va lontan

NicoKid ha scritto:

Puoi usare RPC. Per esempio, NFS e Samba si basano su RPC.
Io ho usato solo MSRPC in ambiente Windows, ma solo che esistono 
implementazioni (per es. FreeDCE) anche per Linux.
-- 
     Carlo Milanesi
 
http://digilander.libero.it/carlmila

 Grazie, Nicola.
Ciao  Manlio

 di glib).
Devo restare in c, altrimenti mi servono anni per rifare il programma :O
Giusto per spiegarmi meglio: uso la select in attesa delle richieste dei
clients e quando arrivano le metto in una coda (un array di strutture).
Inoltre sempre tramite la stessa select invio le eventuali risposte. Il
costrutto che ho fatto e' parecchio complicato e pieno di FD_SET ed FD_CLR.
Insomma vorrei rifare tutta la parte di comunicazione client/server.
Mi pare di aver capito che dovrei usare libevent al posto della select,
giusto?


Carlo Milanesi wrote:

Non ho ben capito la cosa. Non ho trovato molta documentazione.


 Grazie, Nicola.
Ciao  Manlio

 kqueue, poll, select).
Va bene mi hai convinto. Oh, se ti viene in mente qualcos'altro fammelo
sapere :)


 Grazie, Nicola.
Ciao  Manlio

 Grazie, Nicola.
Ciao  Manlio

 Non ho ben capito la cosa. Non ho trovato molta documentazione.
In effetti RPC (Remote Procedure Call) non e' una libreria, ma una
tecnica di programmazione, supportata da vari standard incompatibili,
che a loro volta hanno varie implementazioni.
Questa e' la definizione in italiano:
http://it.wikipedia.org/wiki/Chiamata_di_procedura_remota
Il resto della documentazione che cito e' in inglese.
Questo e' un tutorial del 1997 su ONC RPC con Linux:
http://www.linuxjournal.com/article/2204
Questo e' il capitolo su RPC di un libro del 1999 sulla programmazione 
di sistema in ambiente Unix:
http://www.cs.cf.ac.uk/Dave/C/node33.html
Questa e' la documentazione del 2004 dell'RPC di SCO UnixWare:
http://ou800doc.caldera.com/en/SDK_netapi/CTOC-rpcpN.intro.html


 (per es. FreeDCE) anche per Linux.
Perchè mettere in mezzo una cosa complessa come RPC?
Ciao  Manlio

 Perchè mettere in mezzo una cosa complessa come RPC?
Perche' l'OP ha chiesto "Ci sono librerie di piu' alto livello?".
RPC e' complessa da implementare, ma e' piu' semplice da usare dei 
socket, nel senso che si scrive meno codice applicativo, e il codice 
applicativo e' piu' comprensibile. In poche parole, e' di piu' alto livello.
Inoltre ha alcuni pregi:
* Permette trasparentemente di far comunicare due computer di diversa 
architettura di processore (per es. un Motorola 68K con un Pentium).
* In teoria, permette trasparentemente di far comunicare due computer 
con diverso sistema operativo, anche se in tal caso ci si deve 
assicurare di avere lo stesso standard di RPC. Per esempio, Samba sotto 
Linux comunica via RPC con il server di file di Windows.
* Gestisce trasparentemente richieste concorrenti.
* Dato che usa dati binari, e' piu' performante di una comunicazione via 
socket in modalita' testo.
* Puo' appoggiarsi a vari protocolli di comunicazione, oltre a TCP/IP. 
Per esempio, in ambiente Windows, si puo' appoggiare alle "named pipe".


 Per esempio, in ambiente Windows, si puo' appoggiare alle "named pipe".
Con opportuni pattern/librerie puoi astrarre il tuo programma dal tipo di 
trasporto usato (TCP, unix domain socket, o named pipe).
Vedi ad esempio Twisted (scritto in Python), ACE (in C++) ed anche Boost 
ASIO.
Il problema è che, detto francamente, molti non sanno programmare e si 
affidano a librerie esterne + ambienti di sviluppo come Eclipse e Visual 
Studio che fanno tutto il lavoro per loro (vedi RPC, ma anche WSDL per le 
web application).
Ciao  Manlio

 web application).
Non credo proprio che chi non sa programmare puo' usare RPC; per lo meno 
direttamente. PC sta per Procedure Call; chi non sa programmare non sa 
che cosa e' una chiamata di procedura.
Invece secondo me il problema sta nella sindrome NIH (Not Invented 
Here). Chi ne soffre non si fida delle librerie sviluppate da altri, 
anche se sono garantite da aziende importanti e se ha a disposizione i 
sorgenti.


 importanti e se ha a disposizione i sorgenti.
No, è la questione "non sparare alle mosche con i cannoni" o meglio, "per 
un dato problema usa sempre la soluzione più semplice".
Nello sviluppare una applicazione di rete, il programmatore deve
1) Individuare il protocollo da usare per la comunicazione
2) Individuare l'eventuale libreria, framework da usare, o, eventualmente,
   decidere se usare direttamente i socket
Sono due punti ben separati.
Nel caso dell'OP mi sembra di capire che ci sia un semplice scambio di 
stringhe, nel qualcaso suggerisco di usare netstring (non è propriamente 
un protocollo):
http://cr.yp.to/proto/netstrings.txt
In una applicazione asincrona il parsing è leggermente più complesso 
rispetto ad una applicazione sincrona, dato che ti occorre mantenere uno 
stato.
Ciao

 potresti avere problemi.
Infatti ho dovuto dividere la struttura che passo nella memoria condivisa in
una struttura che scrive solo il processo A e il B la legge e una struttura
che fa l'opposto.
