Discussion :

[Whisperer]

Bonjour,

J'aimerai pouvoir détecter, avec un systeme d'évenement dans l'idéal, lorsque un client (Socket ou TcpClient) se déconnecte volontairement ou involontairement de la socket serveur.

Je n'ai réussi à trouver aucun évenement avec les sockets ... Pourtant, il me semble que détecter la connexion/déconexion d'un client est une fonctionalité qui doit etre souvent utilisée par les développeurs .

Merci pour votre aide

[Skyounet]

Y'a pas d'évènement mais tu peux vérifier si tu es déconnecté avec la propriété Available (lance une exception si deco), ou la méthode Poll avec SelectRead comme mode. Il retourne true si tu as quelque chose à lire ou si tu es déconnecté.

Ensuite tu essayes de lire si tu reçois 0 octets c'est que tu es deco sinon c'est que y'avait quelque chose à lire.

[Whisperer]

Merci Skyounet.

Autrement dit, il va falloir que je me gère un thread qui tourne en boucle , et qui écoute les déconnexions éventuels des clients?

Je trouve quand meme bizarre que ca ne soit pas supporté nativement car c'est quand meme un pattern connu (gestion des clients par un serveur).

Le fait d'avoir un serveur qui entretient la liste des clients connectés, et qui enlève ceux qui sont déconnectés. ou qui se déconnectent intempestivement de cette liste, me semble etre une manipulation souvent faite ...

[StormimOn]

Je me trompe peut être, mais il me semble qu'en cas de déconnexion (voulue ou non), la méthode Receive (et son équivalent asynchrone) renvoie une longueur de données reçues à 0. A vérifier néanmoins.

[Skyounet]

Je me trompe peut être, mais il me semble qu'en cas de déconnexion (voulue ou non), la méthode Receive (et son équivalent asynchrone) renvoie une longueur de données reçues à 0. A vérifier néanmoins.

C'était comme ça en C, alors ça doit pas être différent je pense.

[Whisperer]

Et bien après plusieurs recherches, il semble que le seul moyen, c'est de lire en boucle dans le flux et tester quand il retourne 0 byte de données.

Si c'est le cas, et si la socket (ou le TcpClient) possède un timeout à l'infini, en lecture, cela veut dire que l'hote distant est fermé ou tombé.

Par contre, il faut faire gaffe que si la socket possède un timeout en lecture, lorsque ce timeout est dépassé, la méthode de lecture dans le flux, retourne 0 byte de donnée sans pour autant que la socket distante soit fermée.

C'est un peu mal foutu je trouve quand meme !