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 ...

[nicolas.sitbon]

Pourquoi ?

Je viens de la dire, select() ne garantie pas dans tous les cas, que tu ne bloqueras pas dans ta fonction d'entrée/sortie.

[Emmanuel Delahaye]

Je viens de la dire, select() ne garantie pas dans tous les cas, que tu ne bloqueras pas dans ta fonction d'entrée/sortie.

Je veux bien une liste de ces cas...

[nicolas.sitbon]

Je veux bien une liste de ces cas...

Tu les as déjà, je sais que tu as le bouquin de stevens (unix network programming) qui explique ces cas.
Un exemple:
un client initie une connexion vers un serveur, il se retrouve dans la 'listen queue' du serveur en attendant le accept(), puis il envoie un RST, à partir de là, on retrouve plusieurs comportement:
- le noyau gère ça comme un grand et rien n'est remonté au process
- une erreur est remonté au process, select() revient avec la socket avec des données à lire (ou écrire) et le accept() échoue
- aucune erreur, le accept() bloque en attendant un autre client

[Emmanuel Delahaye]

Un exemple:
un client initie une connexion vers un serveur, il se retrouve dans la 'listen queue' du serveur en attendant le accept(), puis il envoie un RST, à partir de là, on retrouve plusieurs comportement:
- le noyau gère ça comme un grand et rien n'est remonté au process
- une erreur est remonté au process, select() revient avec la socket avec des données à lire (ou écrire) et le accept() échoue
- aucune erreur, le accept() bloque en attendant un autre client

Bizarre qu'il y ait ces différences. C'est pas normalisé par POSIX tout ça ?

La logique voudrait que select() se débloque et que accept(), send[to]() et recv[from]() se débloquent avec un code d'erreur (INVALID_SOCKET pour accept() et SOCKET_ERROR pour les autres).

[nicolas.sitbon]

Bizarre qu'il y ait ces différences. C'est pas normalisé par POSIX tout ça ?

Il y a des lacunes, qui ne sont d'ailleurs toujours comblées dans POSIX 2008...

[souviron34]

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 ...

Je veux bien une liste de ces cas...

une IHM qui affiche des données qui arrive temps réel, mono thread.

tu as besoin d'être non-bloquant pour gérer les événements graphiques. Mais tu veux recevoir (et éventuellement afficher) les données quand elles arrivent...

tu es déjà dans un while(1) pour le traitement des événements graphiques, et il doit rester prioritaire si tu ne veux pas que l'appli gèle...

[Emmanuel Delahaye]

une IHM qui affiche des données qui arrive temps réel, mono thread.

Oui, mais ça c'est à cause du 'mono thread' qui n'est clairement pas adapté à la situation... L'IHM, ça se met dans un thread de priorité faible... (on va pas se laisser emm... par le clickodrome...)

Je continue de penser que la solution 'threads' est plus universelle que select() et les polling de fonctions non bloquantes... (et il y a de fortes chances qu'elle consomme moins de CPU ...).

Si j'ai bien suivi, Chrome, le navigateur de Google est construit comme ça...

http://www.google.com/googlebooks/chrome/index.html

[nicolas.sitbon]

Oui, mais ça c'est à cause du 'mono thread' qui n'est clairement pas adapté à la situation... L'IHM, ça se met dans un thread de priorité faible... (on va pas se laisser emm... par le clickodrome...)

Je continue de penser que la solution 'threads' est plus universelle que select() et les polling de fonctions non bloquantes... (et il y a de fortes chances qu'elle consomme moins de CPU ...).

Si j'ai bien suivi, Chrome, le navigateur de Google est construit comme ça...

http://www.google.com/googlebooks/chrome/index.html

non chrome utilise un modèle différent avec un process par onglet pour la sécurtié, la performance n'entre pas en compte sur ce point là, en revanche comme je l'ai dis dans un autre post il n'y a pas si longtemps, pour le moment, l'approche monothread/évènementiel/non bloquant est toujours la plus performantes sur les serveurs web et assimilé (lighttpd, haproxy qui est vraiment impressionant).

[Emmanuel Delahaye]

l'approche monothread/évènementiel/non bloquant est toujours la plus performantes sur les serveurs web et assimilé (lighttpd, haproxy qui est vraiment impressionant).

Serveur, d'accord.

[souviron34]

Oui, mais ça c'est à cause du 'mono thread' qui n'est clairement pas adapté à la situation... L'IHM, ça se met dans un thread de priorité faible... (on va pas se laisser emm... par le clickodrome...)

Je continue de penser que la solution 'threads' est plus universelle que select() et les polling de fonctions non bloquantes... (et il y a de fortes chances qu'elle consomme moins de CPU ...).

Si j'ai bien suivi, Chrome, le navigateur de Google est construit comme ça...

http://www.google.com/googlebooks/chrome/index.html

je suis bien d'accord que select n'est justement pas la bonne méthode

Sur le fond du problème : dans le principe.. Pourquoi faire une action qui attend indéfiniment une réponse, alors que justement le principe même de la programmation événementielle ET de la conception en couches ET de la conception Objet serait au contraire de faire une action uniquement quand on en a besoin ??


C'est comme si tu conduisais une voiture et que ton oeil/cerveau ne suffit pas, qu'il te faudrait un ordi permanent pour surveiller la route pour prendre en compte les événements innatendus, alors que ton oeil/cerveau seraient bloqués sur la conduite... C'est absurde dans le principe même... On est multi-tâches, avec une capacité à être interrompu, et on gère ces interruptions..

Et heureusement que les centraux téléphoniques, les circuits électroniques, etc et fonctionnent sur ce principe..

Pourquoi devrait-il en être autrement parce que c'est un ordi ?

(qui plus est, je me répète, mais c'était la manière de fonctionner normale en informatique dans le monde autre que M$ avant 2000. C'est juste parce que M$ ne traitait pas vraiment les asynchrones, ou en tous cas pas en couches (puisqu'il lui fallait un id (handle) de fenêtre dans le handler))

[nicolas.sitbon]

Pourquoi devrait-il en être autrement parce que c'est un ordi ?

Je peux comprendre l'argument d'Emmanuel dans le fait d'utiliser des threads car, en général, cela simplifie la programmation, et donc limite les bugs (surtout pour un débutant). D'ailleurs ce n'est pas le seul à le dire, Richard Stevens, en fait la démonstration dans son ouvrage Unix Network Programming, si mes souvenirs sont bons, il faut quelque chose comme 5 fois plus de ligne de code pour faire l'équivalent en monothread/non bloquant. L'argument se justifie donc.

[souviron34]

Serveur, d'accord.

Je peux comprendre l'argument d'Emmanuel dans le fait d'utiliser des threads car, en général, cela simplifie la programmation, et donc limite les bugs (surtout pour un débutant). D'ailleurs ce n'est pas le seul à le dire, Richard Stevens, en fait la démonstration dans son ouvrage Unix Network Programming, si mes souvenirs sont bons, il faut quelque chose comme 5 fois plus de ligne de code pour faire l'équivalent en monothread/non bloquant. L'argument se justifie donc.

ça peut se justifier à mon avis peut-être pour les débutants (et encore, je ne crois pas que ce soit une bonne solution de leur enseigner la facilité), mais dans le fond du problème je pense que justement c'est la séparation client/serveur qui pose le fond du problème..

Si l'on se dit que l'on fait une bibliothèque à partir de laquelle on pourra fabriquer des clients OU des serveurs, la remarque d'Emmanuel tombe à l'eau.

Alors peut-être que le code est plus long, mais le principe d'une bibliothèque est d'être utilisable (facilement) par n'importe qui...

C'était mon cas et la raison pour laquelle je n'avais pas porté sous Win, le Win Handle brisant la notion de couche nécessaire à une bibliothèque portable se situant juste au dessus de la couche transport.


Je peux comprendre l'argument, mais je trouve que cette "mode" est une solution injustifiée et non adaptée dans son principe à un problème dont la solution existait et fonctionnait correctement...

[nicolas.sitbon]

Le détail du handle résulte d'une chose que tu ne prends pas en compte:
- windows est à la base fait pour du desktop
- Unix est à la base fait pour des serveurs

Cela implique des avantages et des inconvénients pour les 2 partis.