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