Discussion :

[oLie]

Bonjour,

J'ai une application qui utilise un socket (winsock2) TCP/IP non-bloquant dont la lecture est cadencé toute les 1 MS.
La fonction recv() me retourne -1 lorsqu'il n'y a pas de données, avec un WSAGetLastError() retournant WSAEWOULDBLOCK.
Lorsque le serveur sur lequel je me connecte clos la session, recv() me retourne 0.
Lorsqu'une rupture liaison a lieu sans qu'un des 2 acteurs de la COM n'en soit à l'initiative, recv() me retourne toujours -1 et WSAGetLastError() me retourne toujours WSAEWOULDBLOCK...

Ma question est la suivante: comment est-il possible de detecter un broken link sur un socket non-bloquant ? ai-je fait quelque chose à l'envers ?

Merci.

[Médinoc]

Je pense que la rupture n'a pas encore été détectée quand tu as WSAEWOULDBLOCK.
Déjà, assure-toi qu'elle soit détectable (SO_KEEPALIVE a un rapport avec ça, il me semble).

[3DArchi]

Les fermetures de sockets, c'est toujours un peu ch...
Bon, déjà, tu peux faire un petit tour vers ces infos.
Pour répondre,
1/ Dans le premier cas, normalement ta socket devrait passer dans un temps plus ou moins long recevoir un WSAECONNRESET.
2/ Dans le second cas (typiquement, tu as débranché le cable), il faut laisser le temps au protocole de se rendre compte que l'autre extrémité n'est plus joignable. De mémoire (donc je peux me tromper), sous Windows, ça doit prendre 1'30 me semble-t-il. Ce sont des paramètres en base de registre.

[oLie]

Merci pour vos réponses.
Le premier cas ne me pose pas de problème en soit, c'etait juste pour situer le comportement que j'aimerais reproduire avec une rupture liaison physique.

Effectivement j'ai déjà regardé du coté de KeepAlive mais je n'ai pas observé de changement.
J'ai tout de même un polling applicatif qui, en cas d'échec de transmission, bascule la session en offline mais ce polling à une étendue de valeurs plutôt large et d'ailleurs il n'est pas fait pour vérifier l'etat de la liaison (mais l'état 'protocolaire' du RTU avec lequel je discute).

Je vais regarder comment paramètrer la période de keepalive pour voir.

[oLie]

Pour info:

L'implémentation du keepalive est facultative et sa présence n'est donc pas garantie, ni sur mon système, ni sur mon RTU - RFC 1122, section 4.2.3.6

Implementors MAY include "keep-alives" in their TCP
implementations, although this practice is not universally
accepted. If keep-alives are included, the application MUST
be able to turn them on or off for each TCP connection, and
they MUST default to off.

D'autre part, le keepAlive ne remplirait pas la fonction voulu (qui est de savoir si réellement mon équipement distant est physiquement en vie sur le socket) mais plutôt de maintenir le lien en vie au moins de son coté (pour par exemple éviter les déconnexions sur inactivité...).

Bref je n'ai pas d'autre alternative que d'utiliser le polling du protocole applicatif, ce qui reste tout de même assez logique (d'où son implémentation régulière dans les protocoles maitres-maitres; ce qui corrige ainsi l'erreur de mon post précédent).
Un broken-link n'est véritablement détectable sur une machine uniquement lorsqu'il a lieu directement entre la machine et le premier équipement réseau auquel elle est connecté (et qui -je pense- est détecté due à l'absence de signal électrique sur la carte).

Pour résumé, fermeture de socket distant et broken-link proche: détectable.
Rupture liaison n'importe où sur le réseau: un système de polling doit être mis en place.

merci tout de même pour votre aide.

[3DArchi]

merci tout de même pour votre aide.

Merci pour toutes ces précisions