Discussion :

[dagos]

Bonjour tout le monde,
je suis en train de développer une application client/serveur en C.
J'utilise les socket unix.
Je souhaite savoir s'il est possible de détecter qu'un client s'est déconnecté (ou que le lien réseau est rompu).

Je sais qu'il est possible de tester le retour de la procédure 'send' lors d'une émission serveur -> client, mais je ne souhaite pas faire cela de cette manière pour les raisons suivantes:
- Les données échangées entre le client et le serveur sont fixes de 16 octets, et je doit donc envoyer 16 octets pour ne pas faire bugguer le protocole de réception du client,
- Le serveur doit traiter des flux de données massifs, et je souhaite donc éviter d'envoyer régulièrement 16 octets pour savoir si la connexion est toujours active (pour optimiser les performances).

J'ai essayé d'utiliser 'send' avec des données nulles (0 octets) mais cela ne fonctionne pas toujours (par exemple, si j'ai 16 clients connectés, seul 2 ou 3 sont vus déconnectés).

Existe t'il une procédure pour savoir si la connexion avec le client est toujours active ?

Merci

[fregolo52]

Euh ...
Quelque part tu devrais être en permanance en écoute du client avec recv, c'est elle qui te dirait que le client est mort.

tu trouveras un super cours ici qui utilise la fonction select.

[Obsidian]

Bonjour,

Existe t'il une procédure pour savoir si la connexion avec le client est toujours active ? Merci

— Soit la connexion est entièrement visible par le système et, dans ce cas, ton processus va automatiquement recevoir un signal SIGPIPE (sauf si tu as passé les flags idoines sur les systèmes d'exploitation qui les reconnaissent) et, dans ce cas, c'est à toi de rattraper ce signal et de gérer la fermeture. C'est ce qui va se passer si tu utilises un modem RTC dont la perte de porteuse est immédiatement détectable ;

— Soit la connexion transite par un réseau sous-jacent et, dans ce cas, il n'y a pas moyen de savoir si une connexion est réellement interrompue si ledit réseau ne t'envoie pas un message de service explicite.

Par exemple, c'est ce qui va se passer sur Internet, où il est officiellement prévu que des paquets puissent se perdre. L'administrateur de ton fournisseur d'accès peut marcher sur un câble réseau dans la salle machine et le débrancher. S'il était relié à un switch intelligent, celui-ci peut renvoyer un Host Unreachable ICMP qui peut remonter jusqu'à ton système. Si c'est un bête hub (ce qui est légal), les paquets vont se perdre dans le vide. Les différents protocoles sont généralement prévus pour réessayer à intervalles fixes. Il se peut également que le trafic soit mis temporairement en buffer. Dans tous les cas, la connexion reprend lorsque l'admin rebranche le câble et ton programme ne s'aperçoit alors de rien, si ce n'est d'un délai inhabituel.

Bon. Ça c'est la théorie. En pratique, débrancher un câble dans une baie, ça provoque beaucoup de perturbations. Mais les préoccupations à prendre en compte dans ton programme restent vraies.

Les clients et serveurs IRC, par exemple, implémentent un message « PING » (en rapport avec la commande éponyme) auquel l'homologue répond « PONG ». Si la réponse n'est pas parvenue dans un délai raisonnable, celui-ci est déclaré décédé. :-)

[souviron34]

je ré-itère mon pointeur sur un code safe :

http://www.developpez.net/forums/d10...t/#post5869608

[skeud]

Euh perso je fait ça de manière plus simple, avec le select comme cité plus haut, tu sais quand tu as un évennement sur ton socket, ensuite lors de la lecture avec recv, si le retour est égal ou inférieur à 0, c'est que ta socket à un souci:
_deconnexion du serveur
_ problème reseu etc....

Donc lors d'un retour egal ou inférieur à zéro je considère que la connexion est perdu, et deconnecte proprement la socket en dégageant tout ce qui la concerne

[Obsidian]

Euh perso je fait ça de manière plus simple, avec le select comme cité plus haut, tu sais quand tu as un évennement sur ton socket, ensuite lors de la lecture avec recv, si le retour est égal ou inférieur à 0, c'est que ta socket à un souci:

Le problème, comme dit plus haut également, c'est que cet événement peut ne pas parvenir jusqu'à ton système et donc jusqu'à ton socket.

[skeud]

Le problème, comme dit plus haut également, c'est que cet événement peut ne pas parvenir jusqu'à ton système et donc jusqu'à ton socket.

Ne pas parvenir? lors de la déconnexion du au reseaux, l'evennement parvient forcément non? sinon il reste la solution de mettre une lifetime sur les socket (on considère qu'au bout de 360 seconde d'inactivité sur une socket, on la déconnecte automatiquement)