Discussion :

[fanfouer]

Bonsoir,

Je suis confronté au besoin de faire une déconnexion propre et obligatoire sur un service distant auquel se connecte un client c++ console que je développe actuellement.

En fait mon client effectue une identification pour signaler son arrivée auprès du service distant et je souhaiterais signaler son départ au moment de sa fermeture.

J'ai correctement défini le destructeur de la classe qui gère les échanges avec le serveur et ce dernier est bien exécuté lorsque le programme se déroule complétement et atteint un point où il se ferme tout seul.
Néanmoins lorsque je ferme la console ou termine le processus, la mémoire est vidée beaucoup plus brutalement et les destructeurs ne sont pas exécutés.

Le service distant nécessite une déconnexion propre pour autoriser une nouvelle connexion ultérieure, si il ne subsiste ne serait-ce qu'un seul cas où la déconnexion n'a pas lieu, je ne pourrai plus me reconnecter la fois suivante.


Il m'étonne de ne rien trouver sur ce type de cas sur le forum ou sur Google plus généralement.
Peut-être que certains auront connu des expériences similaires, merci par avance.

[Bousk]

Bonsoir,

sans vraiment répondre : que se passera-t-il si la connexion est tout simplement perdue ? (cable arraché ou que sais-je)
Impossible de se reconnecter

Il faudrait nous en dire plus sur ce que tu fais, parce que ça parait au mieux bancal.
Est-ce le serveur qui interdit la reconnexion dans ce cas ? Ou le client ?

Il faut en général prévoir un timeout à partir duquel on affirme que le client est mort (côté serveur et/ou le serveur côté client), sans être passé par la case déconnexion.

[fanfouer]

Bonsoir Bousk,

sans vraiment répondre : que se passera-t-il si la connexion est tout simplement perdue ? (cable arraché ou que sais-je)
Impossible de se reconnecter

Si la connexion est perdue ca n'est pas un soucis.
Tant que le processus n'est pas mort il conserve en mémoire un jeton qu'il fourni à chaque accès entre son arrivée et son départ.

Il faudrait nous en dire plus sur ce que tu fais, parce que ça parait au mieux bancal.

Je déploie une solution distribuée qui communique avec une tête de réseau pour recevoir ses ordres (non c'est pas un botnet et quand bien même je ne prévois d’exécuter l'outil que sur mes machines).
Pour se faire des clients apparaissent et disparaissent. Ils vont se connecter au service, ne serait-ce que pour signaler leur présence et recevoir leurs ordres.

Chaque client est unique à tout instant sur le réseau, deux clients avec le même identifiant ne peuvent pas co-exister.
Tous les clients sont par contre équivalents en termes de capacités, on peut les intervertir en modifiant leur configuration.
Vu qu'on peut assez facilement la changer d'ailleurs, le premier arrivé sur le service est le premier servi et les demandes de connexion suivantes avec le même identifiant seront refusées par le serveur.
Mais si un client reste identifié comme présent sur le serveur alors qu'il s'est barré, et bien il ne pourra logiquement pas se reconnecter.

Il faut en général prévoir un timeout à partir duquel on affirme que le client est mort (côté serveur et/ou le serveur côté client), sans être passé par la case déconnexion.

C'est déjà mesuré mais ça sort comme une alarme plutôt qu'une déconnexion automatique.
Il est possible qu'un client plante ou qu'il y ai une coupure de courant dans sa zone. Du coup la tête de réseau doit le signaler comme une alarme plutôt que de faire une déconnexion automatique qui ne sera vue par personne.

J'espère être clair et n'hésites pas à formuler des critiques sur ms hypothèses si tu le souhaites.

[Emmanuel Deloget]

Bonsoir Bousk,


Si la connexion est perdue ca n'est pas un soucis.
Tant que le processus n'est pas mort il conserve en mémoire un jeton qu'il fourni à chaque accès entre son arrivée et son départ.


Je déploie une solution distribuée qui communique avec une tête de réseau pour recevoir ses ordres (non c'est pas un botnet et quand bien même je ne prévois d’exécuter l'outil que sur mes machines).
Pour se faire des clients apparaissent et disparaissent. Ils vont se connecter au service, ne serait-ce que pour signaler leur présence et recevoir leurs ordres.

Chaque client est unique à tout instant sur le réseau, deux clients avec le même identifiant ne peuvent pas co-exister.
Tous les clients sont par contre équivalents en termes de capacités, on peut les intervertir en modifiant leur configuration.
Vu qu'on peut assez facilement la changer d'ailleurs, le premier arrivé sur le service est le premier servi et les demandes de connexion suivantes avec le même identifiant seront refusées par le serveur.
Mais si un client reste identifié comme présent sur le serveur alors qu'il s'est barré, et bien il ne pourra logiquement pas se reconnecter.


C'est déjà mesuré mais ça sort comme une alarme plutôt qu'une déconnexion automatique.
Il est possible qu'un client plante ou qu'il y ai une coupure de courant dans sa zone. Du coup la tête de réseau doit le signaler comme une alarme plutôt que de faire une déconnexion automatique qui ne sera vue par personne.

J'espère être clair et n'hésites pas à formuler des critiques sur ms hypothèses si tu le souhaites.

Ping !

Plus prosaïquement, le serveur envoie régulièrement un court message à son destinataire (en NODELAY), et celui-ci doit répondre de même. S'il ne le fait pas, alors il est considéré comme étant mort (c'est la technique utilisée par les serveurs IRC pour déterminer si un client est toujours actif).

Je ne vois guère d'autre solution : tu n'auras jamais la possibilité d'intercepter la fermeture forcée du programme client (c'est impossible, pour des raisons de sécurité : si je peux intercepter un tel signal et exécuter du code en retour, alors je fork et hop, mon programme ne peut plus être tué).

[fanfouer]

Bonjour Emmanuel,

Ping !

Plus prosaïquement, le serveur envoie régulièrement un court message à son destinataire (en NODELAY), et celui-ci doit répondre de même. S'il ne le fait pas, alors il est considéré comme étant mort (c'est la technique utilisée par les serveurs IRC pour déterminer si un client est toujours actif).

Dans mon cas le serveur ne peut pas envoyer de message aux clients.
Les communications sont systématiquement à l’initiative des clients puisque des éléments comme des NAT ne permettent pas de les atteindre directement.
Le postulat est que les clients doivent être le plus souvent en activité donc contactent le serveur dès qu'ils le peuvent pour demander du travail.

C'est ce qui pose certains problèmes ici je pense.

Je ne vois guère d'autre solution : tu n'auras jamais la possibilité d'intercepter la fermeture forcée du programme client (c'est impossible, pour des raisons de sécurité : si je peux intercepter un tel signal et exécuter du code en retour, alors je fork et hop, mon programme ne peut plus être tué).

En effet je comprends ce point de vue.

Il faut que je trouve un moyen pour différencier une inactivité d'une déconnexion simple pour éviter les alarmes côté serveur mais cela semble être une quête sémantique et protocolaire assez étriquée

[Davidbrcz]

Ajoute dans ton code un message périodique à destination du serveur. Si au bout d'un certain délais le serveur ne reçoit rien le serveur n'a qua considérer que le client est déconnecté.

[fanfouer]

Ce sera certainement la solution par défaut oui.

Cependant je souhaiterai différencier les simples plantages des déconnexions franches.
D'où l'idée pour moi d'envoyer une requête au moment de la fermture du processus.

Pour l'instant toutes les requêtes sont loguées donc l'inactivité est détectable sans message supplémentaire.
Cette inactivité est cependant traduite en alerte et pas en déconnexion comme je le disais plus haut.

[white_tentacle]

Tu peux récupérer le signal SIGTERM et faire un traitement quand il survient.

Par contre, tu ne pourras rien faire pour le SIGKILL…

[fanfouer]

Bonjour White_tentacle,

Cette possibilité m’intéresse, est-il possible de le faire avec du code C++ natif?

[Emmanuel Deloget]

Bonjour White_tentacle,

Cette possibilité m’intéresse, est-il possible de le faire avec du code C++ natif?

Oui, via l'utilisation de la fonction signal() (ou sigaction(), pour être plus moderne ; si tu utilises des threads, la librairie pthread propose aussi des services similaires).

[imperio]

Lorsqu'un client se déconnecte, si tu tentes de lire sur sa socket tu recevras une erreur (par contre si t'écris ça plantera, attention donc !). La solution des signaux n'est possible que sur environnement unix donc attention si tu vas sous windows.

Tu peux récupérer le signal SIGTERM et faire un traitement quand il survient.

Par contre, tu ne pourras rien faire pour le SIGKILL…

Le signal SIGQUIT non plus, donc la seule solution pour éviter tout ça serait de lancer un service qui se chargerait de relancer ton programme à chaque fois qu'il se fermerait (fork, wait).

[bretus]

Bonsoir,

Cependant je souhaiterai différencier les simples plantages des déconnexions franches.
D'où l'idée pour moi d'envoyer une requête au moment de la fermture du processus.

Il n'y a pas plus simple que les SIGTERM, SIGKILL, etc...? Du style : Un message de déconnexion lors d'une déconnexion propre couplé à l'idée du "ping" périodique.

Si le client ne fait plus "coucou" et qu'il n'a pas dit qu'il se déconnectait => Problème.

Ça me semble moins sensible aux coupures réseaux ou matérielles non?

[fanfouer]

Bonjour à tous,

Oui, via l'utilisation de la fonction signal() (ou sigaction(), pour être plus moderne ; si tu utilises des threads, la librairie pthread propose aussi des services similaires).

La solution des signaux n'est possible que sur environnement unix donc attention si tu vas sous windows.

Le signal SIGQUIT non plus, donc la seule solution pour éviter tout ça serait de lancer un service qui se chargerait de relancer ton programme à chaque fois qu'il se fermerait (fork, wait).

Oui en effet si je cherche à produire du c++ natif c'est pour être portable sur des environnements unix comme des windows.
Sur ce point, l'utilisation des signaux ne permettrait pas d'être compatible avec windows et ça me pose un soucis.

Lorsqu'un client se déconnecte, si tu tentes de lire sur sa socket tu recevras une erreur (par contre si t'écris ça plantera, attention donc !).

Il n'y a pas de sockets entre le client et le serveur.
Je travaille en HTTP et la connexion est fermée à chaque échange.
On évite ainsi d'écrire dans un socket fermé en effet.

Bonsoir,
Il n'y a pas plus simple que les SIGTERM, SIGKILL, etc...? Du style : Un message de déconnexion lors d'une déconnexion propre couplé à l'idée du "ping" périodique.

Si le client ne fait plus "coucou" et qu'il n'a pas dit qu'il se déconnectait => Problème.

Ça me semble moins sensible aux coupures réseaux ou matérielles non?

Je crois que je vais opter pour cela, ce sera moins contraignant.

Cela va impliquer quelques remises en question mais au pris d'une certaine compatibilité.
On peut considérer ce problème comme "résolu" même si aucune solution viable au problème initial n'est à envisager.

Merci à tous.