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)

[souviron34]

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)

non ça ne provient pas forcément...

Entre les sockets gelés (frozen sockets), et les différences d'interprétation des CTRL-C CTRL-Z, ou kill, plus les coupures éventuelles dans un lien au milieu, on n'est pas toujours prévenu...

D'autre part, considérer 360 secondes comme une limite est vraiment .... court... : j'avais des serveurs sur lesquels je pouvais n'avoir aucune donnée pendant 2 mois, puis 1 000 par seconde, puis 1 tous les 15 jours...


Donc, penser général et safe est le seul truc safe..

[skeud]

Donc, penser général et safe est le seul truc safe..

c'est à dire?

[souviron34]

c'est à dire?

je viens de l'expliciter :

Entre les sockets gelés (frozen sockets), et les différences d'interprétation des CTRL-C CTRL-Z, ou kill, plus les coupures éventuelles dans un lien au milieu, on n'est pas toujours prévenu...

D'autre part, considérer 360 secondes comme une limite est vraiment .... court...

Donc prendre TOUTES précautions : signals, polls..

C'est toi qui dit :

Euh perso je fait ça de manière plus simple

Sauf que ça n'embrasse pas TOUS les cas que l'on peut rencontrer...

[skeud]

Ah ok je croyais que tu disais ça dans le sens rajouter des spécifications à ce que tu as dit .

Dans quel cas on peut choper un SIGPIPE avec une socket?

[orfix]

C'est quoi comme application ?
Ne peux-tu pas attendre d'avoir quelque chose d'utile à envoyer au client ?

[souviron34]

@skeud :

je ne sais plus exactement (j'ai codé et testé ça il y a presque 13 ans), mais si mes souvenirs sont bons un truc un peu comme lancer via une console, puis tuer la console, avoir un process "zombie" sous unixoides.. et le tuer..

Mais c'est peut-être pas ça .. Trop lointain.

Je me souviens en tous cas qu'on avait fait des tests assez exhaustifs (le client/serveur devait tourner 24h/24 7/7 365), entre des serveurs HP, des PCs linux, des PCs Win, en effectuant tout un tas de tests (par exemple purement et simplement éteindre ou débrancher le PC d'un coup), et que on tombait sur des cas étranges non détectés...

D'où une pléthore de tests pour tout gérer...

[skeud]

Ah oui effectivement, mes connaissance en serveur se limittant aux étude (max 15min pour un serveur lancer, et test a la con genre ctrl+C ....) je ne connais pas tout les cas d'erreur possible du au kevin qui tape dessus pour faire de la techtonique

[souviron34]

ben oui, mais c'est bien pour ça qu"on dit "de manière sûre" ...

Parce que il n'y a pas que "le kevin qui tape dessus pour faire de la techtonique" ...

La foudre qui tombe et un disjoncteur qui arrête toute une salle des machines, un backup qui se passe mal et bloque un système, un disque plein, etc etc etc...

La réalité dépasse très souvent la fiction, et les scénarios de "hangup" sont rarement "clean"...

Encore une fois, la différence entre la théorie et la pratique...

[skeud]

théoriquement ça marche

[dagos]

merci pour vos réponses.
Pour SIGPIPE, le signal n'est généré que si j’appelle la procédure 'send' (cela dit j'ai pas essayé avec des données nulles).

J'utilise 'recv' en mode non bloquant donc ça ne m'aide pas beaucoup ('recv' retourne 0 même si le socket client est fermé).

Il faut donc que je me penche sur 'select' et 'poll' si j'ai bien compris...