Discussion :

[iMaTh]

Bonjour,
J'ai un problème, je n'arrive pas à détecter quand la connection à la socket est down.
Par down j'entends que je débranche le cable ethernet entre mes deux machines qui discutent par socket.

A savoir que :

Ma socket est non bloquante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

fcntl(sock, F_SETFL, O_NONBLOCK | fcntl(sock, F_GETFL));

j'ai essayé ceci pour pouvoir déterminer si la connection est down :
( ce bout de code tourne dans une boucle infinie dans un thread )

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
        res = read(sock,  msg, sizeof(msg));
 
        if (res == 0) {
            cout << "socket deconnecté 1" << endl;
        }
        if ( errno == EAGAIN ) {
            cout << "socket deconnecté 2" << endl;
        }

J'ai dans l'idée de detecter cela pour, en cas de deconnection faire régulièrement des tentatives de reconnection, ainsi mon programme sera autonome.

Merci de me faire par de vos idées, je me retrouve un peu désarmé face à la situation.

[Emmanuel Delahaye]

J'ai un problème, je n'arrive pas à détecter quand la connection à la socket est down.
Par down j'entends que je débranche le cable ethernet entre mes deux machines qui discutent par socket.

Un débranchement de cable ne signifie pas une déconnexion. Celle-ci intervient au bout d'un moment si les 'timeout' arrivent à expiration. Ca peut faire plusieurs secondes, voire plus...

A savoir que :

Ma socket est non bloquante :

C'est pas une bonne idée... Avec une socket bloquante, les choses sont claires : une déconnexion se traduit par un déblocage et un retour valant 0.

[souviron34]

j'avais posté il y a peu quelque chose sur le forum Linux :

comment détecter certaines déconnections de sockets : post #3

[nicolas.sitbon]

C'est pas une bonne idée... Avec une socket bloquante, les choses sont claires : une déconnexion se traduit par un déblocage et un retour valant 0.

Personnellement, je préfère le modèle non bloquant/événementiel à un modèle bloquant/threadé, les choses sont tout aussi claires, en non bloquant, l'évènement est signalé dans les fonctions de multiplexage.

[Emmanuel Delahaye]

Personnellement, je préfère le modèle non bloquant/évenementiel à un modèle bloquant/threadé, les choses sont tout aussi claires, en non bloquant, l'évènement est signalé dans les fonctions de multiplexage.

En évènementiel, on a pas besoin d'être non-bloquant. Il suffit d'utiliser select() / poll() ...

[nicolas.sitbon]

En évènementiel, on a pas besoin d'être non-bloquant. Il suffit d'utiliser select() / poll() ...

Si tu es monoprocess/monothread, tu as intérêt à être non bloquant, il y a quelques cas à la con ou tu peux quand même bloquer malgré la suggestion de la fonction de multiplexage.

[Emmanuel Delahaye]

Si tu es monoprocess/monothread, tu as intérêt à être non bloquant, il y a quelques cas à la con ou tu peux quand même bloquer malgré la suggestion de la fonction de multiplexage.

Pourquoi ? de toutes façon avec select() (qui est bloquant) tu fais une boucle unique dans le processus/thread unique et c'est tout. Si c'est sous Windows, il faut utiliser WaitForMultipleObject() ou un truc du même genre, car select() ne fonctionne que sur les sockets ...