Newsgroup: it.comp.os.linux.development
Titolo: Problemi con primitive client-server C-linux

Trattasi di programmazione client-server con socket Unix e Co.
Domanda 1)
uso dei timer di timeout con select(),
senza farmi troppi problemi ho settato i timer infiniti lasciando di
fatto la select bloccata in attesa permanente di nuove connessioni o di
messaggi da leggere.
Dovendo pero` gestire le SIGNAL di interruzione ho bisogno, una volta
ricevuto ad esempio un CTRL C, di rimanere sotto select per aspettare un
messaggio prima di terminare il processo. Succede che riscontro un
errore di select del tipo "Interrupt system call". Un collega mi
consiglia di settare a zero i timeout della select, ovvero di renderla
non bloccante.
E` l'unica via?
Comporta altri effetti?
Domanda 2)
read di 0 byte dalla socket di lettura,
non viene considerato un errore ma di cosa e` sintomo?
Di un errore di write dall'altro lato?
Puo` capitare in conseguenza della caduta della socket dell'altro lato?
Come si puo` gestire?
Grazie e saluti a tutti
-- 
Giuseppe R.
E-mail: mailto:
giuseppe...@SPAMnetit.alcatel.it
--
Posted from 
ns.alcanet.it
 [194.243.74.35] 
via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 wrote:
-> Trattasi di programmazione client-server con socket Unix e Co.
-> 
-> Domanda 2)
-> read di 0 byte dalla socket di lettura,
-> non viene considerato un errore ma di cosa e` sintomo?
-> Di un errore di write dall'altro lato?
-> Puo` capitare in conseguenza della caduta della socket dell'altro lato?
Tutti e tre volendo. Se non leggi nulla dalla socket, puo' essere:
a) che la trasmissione sia terminata
b) che la trasmissione non sia neanche iniziata
c) che la trasmissione non e' pronta.
d) che chi doveva trasmettere sia morto
e) che non ci siano dati da trasmettere.
Il punto a) dovresti saperlo.
I punti b) e c) dipendono dal programma di trasmissione, se sta interrogando un database
puo' essere che non abbia finito la query e tu hai chiesto i risultati troppo
presto.
Il punto d) lo puoi scoprire solo in altro modo, ad esempio facendo polling con 
un carattere di controllo (vedi il ping)
Il punto e), non e' fatto bene il server, dovrebbe restituire un valore di
mancanza dati.
Per come gestirlo dipende cosa fa il tuo programma e dipende dal cosa si aspetta il
programma che legge. Potresti anche considerarlo un errore se e' prevista una 
risposta. Io normalmente lo considero un errore perche' mi aspetto sempre un valore
di ritorno ad esempio.
bye
Gianluca
-- 
Home Page                	Contro i brevetti del sw     Boicotta Microsoft
www.infinito.it/utenti/chewbe
 
no-patents.prosa.it/
 
www.boycott-ms.org/
 
"If we have to file a thousand lawsuits a day, we'll do it.
It's less expensive than losing CONTROL of YOUR creative works."
---Jack Valenti, President and CEO, Motion Picture Association of America

 
Rilancio approfittando della tua pazienza raccontandoti meglio come si
inserisce il problema che ti ho esposto (insieme ad altri problemi).
Puo` essere il punto 2) che elenco sotto la causa della read 0?.
Alla base di tutto c'e` una scarsa comprensione dei meccanismi "interni"
d gestione della comunicazione client-server usando socket unix in
dominio internet.
Scenario: un client scrive regolarmente a un server. In seguito a
determinati vincoli che non espongo ha la necessita` di connettersi a un
altro server (server 2) di cui riceve i dati di connessione dal vecchio
server (server 1) chiudendo col primo. Per non ritrovarmi su un binario
morto io provo a fargli fare la nuova connessione, se va ok chiudo la
vecchia e scrivo sulla nuova. Noto pero` degli effetti indesiderati come
ad esempio il fatto che il vecchio server continua a ricevere quello che
io voglio scrivere SOLO al nuovo finche` non opera una close della
socket con cui comunica al client (quella ottenuta dall'accept per
intenderci).
Entrambi i server sono concorrenti singolo processo e sotto select
Pseudo-codice del client
main
  int sock_scrittura, temporaneo;
  struct sockaddr_in s_scrittura;
  int lungh_s_scrittura;
...
if "condizione X"
  temporaneo=sock_scrittura;
  sock_scrittura=socket(AF_INET, SOCK_STREAM, 0);
  "riempi i campi di s_scrittura con i dati di server2 arrivati da
server1"(*)
  if connect(sock_scrittura, &s_scrittura, lungh_s_scrittura)<0
    close(sock_scrittura);
    sock_scrittura=temporaneo;
    write(sock_scrittura, "scrivi a server1 fallimento connect server2")
  else
    close(temporaneo);
    write(sock_scrittura, "scrivi a server2")
Domande:
1) che legame c'e` tra il descrittore di socket e la struttura di tipo
sockaddr_in che gli compete?
Dev'esserci una abbinamento 1 a 1 e quindi io devo sdoppiare tutto,
anche la struttura sockaddr_in e non solo il socket descriptor?
Ovvero l'istruzione (*) compromette "l'integrita`" del canale di
comunicazione?
Cio` non mi torna molto perche` la write richiede solo il descrittore di
socket come parametro della socket e io mi aspetto che ad esso ci siano
legati indissolubilmente i dati del canale di comunicazione da usare
(porta e address del server)
2) che succede all'estremita` server di un canale di comunicazione
quando lato client viene chiuso l'altro estremo con una close? Intendo a
livello di maschera di select, puo` succedere che vengano rilevati
segnali "spuri"?
Grazie e ciao
