[Socket C] Identificare disconnessione client

[tomminno]

Come si fa a sapere quando un client si disconnette?
Io me ne accorgo solo su recv. Esiste un altro modo?

[ilsensine]

1) recv ritorna 0; oppure
2) send ritorna -1 con errno==EPIPE; oppure
3) poll indica POLLHUP oppure POLLERR; oppure
4) ...semplicemente non te ne accorgi. In caso di chiusura non pulita del canale (può accadere per varie cause), possono trascorrere anche ore prime che il layer tcp notifichi la condizione di errore per timeout. Ti consiglio di attivare il flag SO_KEEPALIVE per abilitare questo controllo.

[maulattu]

1) recv ritorna 0; oppure
2) send ritorna -1 con errno==EPIPE; oppure
3) poll indica POLLHUP oppure POLLERR; oppure
4) ...semplicemente non te ne accorgi. In caso di chiusura non pulita del canale (può accadere per varie cause), possono trascorrere anche ore prime che il layer tcp notifichi la condizione di errore per timeout. Ti consiglio di attivare il flag SO_KEEPALIVE per abilitare questo controllo.

sto provando a testare questi eventi con un semplice server che legge da socket (uso la poll(...)) e un client che invia un byte alla volta al server.
per verificare la chiusura brutale di un socket, killo con il segnale 9 il client.
il punto è che:
1) la poll (sul server) non dà né POLLHUP, né POLLERR
2) me accorgo di ciò se faccio + chiamate alla recv sul server (la prima restituisce 0) che mi danno errno = 29 ("Illegal seek") (non sempre però, a volte ritornano sempre 0)

vorrei sapere se setto correttamente il socket TCP con il flag SO_KEEPALIVE sul server (è necessario farlo anche sul client?):

..
sd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
setsockopt(sd, IPPROTO_TCP, SO_KEEPALIVE, &on, sizeof(on));
bind(sd, (struct sockaddr *) &server_addr, sizeof(server_addr));
listen(sd, MAX_CONNECTIONS);
...
...
new_sd = accept(sd, (struct sockaddr *) &client_addr, &client_len);
setsockopt(new_sd, IPPROTO_TCP, SO_KEEPALIVE, &on, sizeof(on));
...

se così fosse giusto, quanto bisognerebbe aspettare in media per avere riscontro dal layer TCP al riguardo di una connessione chiusa in modo brutale (es: il mio client crasha)?

EDIT: ho provato giusto ora a far crashare il client dopo un tot di trasmissioni provocando un segmentation fault (accesso al contenuto di un puntatore inizializzato a NULL), ma le casistiche sopra (poll e recv) non "segnalano" mai l'errore (niente POLLHUP, POLLERR, recv < 0 con errno > 0)

grazie:read:

[ilsensine]

sto provando a testare questi eventi con un semplice server che legge da socket (uso la poll(...)) e un client che invia un byte alla volta al server.
per verificare la chiusura brutale di un socket, killo con il segnale 9 il client.
il punto è che:
1) la poll (sul server) non dà né POLLHUP, né POLLERR
Allora darà POLLIN

2) me accorgo di ciò se faccio + chiamate alla recv sul server (la prima restituisce 0) che mi danno errno = 29 ("Illegal seek") (non sempre però, a volte ritornano sempre 0)
0 non è un errore, il valore di errno è indefinito se la recv ritorna 0.
La notifica è stata effettuata con successo, recv==0 vuol dire EOF (nel caso dei socket, disconnessione).


se così fosse giusto, quanto bisognerebbe aspettare in media per avere riscontro dal layer TCP al riguardo di una connessione chiusa in modo brutale (es: il mio client crasha)?
Ore. Come ti ho detto, il keep alive becca eventi di disconnessione non banali (ad es. un nodo di rete intermedio che si blocca, ecc.) che rendono di fatto impossibile lo scambio dei pacchetti tra le macchine.
Se client e server sono sulla stessa macchina (o su macchine raggiungibili, senza problemi nella connessione di rete) riuscirai sempre ad accorgerti della disconnessione in caso di crash di uno dei programmi.
Se invece stacchi (prova!) la scheda di rete a uno dei due computer, i programmi non si accorgeranno della disconnessione (è corretto, il tcp è pensato per questo: una volta ricollegato il cavo, i programmi riprenderanno a funzionare). In questo caso il keep alive viene in aiuto, se la disconnessione si prolunga per parecchio tempo.

[tomminno]

Io per risolvere il problema ho implementato un ping applicativo, avevo bisogno di sapere abbastanza velocemente (15 secondi max) se un client era disconnesso, però lavoravo in LAN.

[ilsensine]

Io per risolvere il problema ho implementato un ping applicativo, avevo bisogno di sapere abbastanza velocemente (15 secondi max) se un client era disconnesso, però lavoravo in LAN.
Questa è la soluzione corretta se si hanno bisogno di timeout brevi.

[71104]

Se invece stacchi (prova!) la scheda di rete a uno dei due computer, i programmi non si accorgeranno della disconnessione (è corretto, il tcp è pensato per questo: una volta ricollegato il cavo, i programmi riprenderanno a funzionare). interessante, però credo che l'esperimento funzioni solo se la si stacca non dalla "parte del computer" ma dall'altra: se per esempio si tratta di un modem USB, a causa dello standard USB il sistema operativo di accorgerà che la periferica è stata rimossa e le reazioni a catena scatenatesi di conseguenza includeranno la disconnessione. se invece stacco il modem dalla linea telefonica... :)

[ilsensine]

interessante, però credo che l'esperimento funzioni solo se la si stacca non dalla "parte del computer" ma dall'altra: se per esempio si tratta di un modem USB, a causa dello standard USB il sistema operativo di accorgerà che la periferica è stata rimossa e le reazioni a catena scatenatesi di conseguenza includeranno la disconnessione. se invece stacco il modem dalla linea telefonica... :)
Forse, ma non è detto. Il traffico IP può viaggiare, in teoria, anche attraverso più di una interfaccia.
Inoltre, solo il computer con il modem se ne può accorgere -- l'altro lato della connessione potrebbe o meno ricevere la notifica.

Non è un problema banale; mi sono capitati programmi rimasti appesi per ore a causa della caduta di una connessione intermedia. Se la stabilità della connessione è un must, occorre implementare dei messaggi di keepalive tra le applicazioni.

[maulattu]

Allora darà POLLIN

0 non è un errore, il valore di errno è indefinito se la recv ritorna 0.
La notifica è stata effettuata con successo, recv==0 vuol dire EOF (nel caso dei socket, disconnessione).



Ore. Come ti ho detto, il keep alive becca eventi di disconnessione non banali (ad es. un nodo di rete intermedio che si blocca, ecc.) che rendono di fatto impossibile lo scambio dei pacchetti tra le macchine.
Se client e server sono sulla stessa macchina (o su macchine raggiungibili, senza problemi nella connessione di rete) riuscirai sempre ad accorgerti della disconnessione in caso di crash di uno dei programmi.
Se invece stacchi (prova!) la scheda di rete a uno dei due computer, i programmi non si accorgeranno della disconnessione (è corretto, il tcp è pensato per questo: una volta ricollegato il cavo, i programmi riprenderanno a funzionare). In questo caso il keep alive viene in aiuto, se la disconnessione si prolunga per parecchio tempo.

stamattina ho dato un'occhiata al buon Stevens (Unix netw. programming vol 1) e mi son chiarito un po' le idee.
sostanzialmente, se la connessione cade in modo pulito (così sembra succedere anche facendola crashare sia provocando un segm fault, sia killandola con segnale 9), la recv ritorna 0 (probabilm anche la send). In caso si usi la poll(...), allora ritornerà POLLIN.

se invece l'host crasha, con l'opzione SO_ERROR del socket avrà valore ETIMEDOUT (idem se si sta in attesa con SO_KEEPALIVE, ma il timeout è di 2 ore :eek: , proprio come diceva ilSensine, altrimenti non me ne accorgo).

se l'host è irraggiungibile, allora con SO_ERROR avrà valore EHOSTUNREACH.

Se client e server sono sulla stessa macchina (o su macchine raggiungibili, senza problemi nella connessione di rete) riuscirai sempre ad accorgerti della disconnessione in caso di crash di uno dei programmi.
sì, questo è il mio caso... dunque tu dici che in caso di crash di uno dei due programmi, mi accorgerò della disconnessione con la poll che darà POLLIN, giusto? :help:
è chiaro che comunque terrò conto anche degli altri casi (timeout con keepalive, host unreachable)...
grazie x le dritte ;)

[tomminno]

Non so se vi è mai capitato di lavorare con connessioni GPRS.
Un vero incubo.
Provate ad immaginarvi una situazione in cui un dispositivo connesso si disconnette e in seguito riconnette ma il centro servizi continua a tenere aperto il vecchio socket e ancora peggio continua a mandare vecchi dati (che viaggiano con ritardi anche di 2/3 minuti) :muro:

[maulattu]

Ne approfitto x chiedere a chi ne sa (ad esempio, il sempre disponibile ilSensine:read: :D ) da cosa può essere causato questo messaggio di errore:
Feb 27 16:00:09 xxx@host inetd[955]: 7006/tcp server failing (looping), service terminated

a questo punto, l'host diventa irraggiungibile :muro:
che dite, è inetd che è andato a prostitute?
:help: