Newsgroup: it.comp.os.linux.development
Titolo: Socket & read (bloccante o no)

Salve,
    Premetto che sto lavorando con socket orientati alla
connessione, mi domandavo, dato che se tento di scrivere su una
socket (sulla quale prima c'era una connessione valida) quando
il peer dall'altro lato del socket e' caduto, il processo scrivente riceve
una SIGPIPE (correggetemi se sbaglio), e quindi riuscirei a rilevarlo,
ma la mia domanda e', se la cosa succede al processo che sta' leggendo?
Mi spiego, io leggo da un socket sul quale c'e' una connessione
valida, il processo che secondo il protocollo da me stabilito
avrebbe dovuto inviarmi dei dati muore, cosa fa il processo ricevente?
1_ Se utilizzo un socket (come lo e' di default) bloccante per la lettura
     resto li in eterno?
2_ Se imposto i flag O_NONBLOCK oppure O_NDELAY con fcntl()
     la read esce (con errore o meno dipende da quale dei due flag si
impostano)
     anche senza dati, ma come faccio a determinare per quanto tempo devo
star
     li a tentare di leggere sul socket prima di accorgermi che mai nessuno
mi spedira'
     mi spedira' qualche cosa?
Insomma per farla breve (vi ho gia' tediato abbastanza :-)) come ci si
comporta in
questi casi? C'e' un modo per sapere se il peer e' ancora vivo?
Grazie a colui (che tra l'altro diventera' il mio guru personale) che
riuscira' a
risolvere questo cavolo di problema


è un po' che non scrivo qualcosa sui socket (leggi forse sono un po'
arrugginito) ma vedo solo questa strada:
1) la macchina (o un link in mezzo) muore => se hai il keepalive attivo sul
servizio che offri se ne accorge e te lo dice
2) muore il processo: il keepalive da tutto ok => devi fare una lettura non
bloccante e aspettare *tu* un tempo massimo di timeout a tuo piacimento...
spero di averti dato almeno una dritta...
------------------------------
Diffida di chi ti da' consigli e poi ti insulta, str%%%o

 risolvere questo cavolo di problema
quale onore... ammesso di esserci riuscito...
-- 
Francesco P. Lovergine

 Francesco P. Lovergine
Intanto ringrazio entrambi per avermi risposto, e volevo proporre
una soluzione, per chiedere un parere e per aiutare chi in futuro
potesse avere il mio stesso problema :
oggi parlando con dei miei amici, (che bei argomenti di discussione :-))
mi e' venuto in mente che si potrebbe utilizzare una read di un
unsigned char su un descrittore di socket bloccante, (e quindi lo stato
di default del socket) messa dopo una select, che ascolta i
cambiamenti in lettura di quel socket, con settato un timeout (della
select),
che sara' il limite massimo di attesa, senza risposta dal parte dell'host.
In questo modo abbiamo che se si puo' uscire dalla select in due modi,
o ci sono dati sul socket, e allora almeno un unsigned char c'e' e il socket
bloccante non da problemi, (se si raggiunge la quantita' di dati voluta si
esce
dal ciclo, altrimenti si ritorna nella select) oppure e' scattato il
timeout,
in questo caso significa che l'host (ammesso il dimensionamento corretto del
timer) ha dei problemi e si puo' gestire la cosa.
Ho detto delle ca##ate?

,

Che differenza c'e' rispetto a fare tutte le recv() bloccanti e
ritentare se l'errore e' dovuto semplicemente ai tempi di ritardo
(la recv() ti ricordo dovrebbe loopare in lettura fino alla
lettura di tutti i dati necessari)? Se hai bisogno di fare
altro durante la ricezione puoi sempre incampsulare la comunicazione
in un processo separato o in un thread. Comunque non ho molto
capito a cosa dovrebbe servire il byte a cui ti riferisci.
Sent via Deja.com
http://www.deja.com/