bonjour,
 
j'aimerais connaitre le méchanisme employé dans un
client telnet pour savoir que le serveur auquel on
est connecté vient de fermer la socket.
En effet, du côté du client, comment savoir que la
socket est fermée même si l'on n'est pas en train
d'envoyer des données?
Je sais que je pourrais me lancer dans l'exploration
des sources d'un client telnet, mais j'aimerais
pouvoir m'éviter cette tâche.
 
merci d'avance.
 
 

bin la couche TCP te renvoie une erreur que ton client catch c'est tout

détecter l'erreur en envoyant des datas, d'accord. Par contre, je voudrais savoir comment cela se passe quand on n'envoie rien... Ou alors un client telnet envoie en permanence des données, même quand l'utilisateur ne demande rien?
L'experience est simple: avec un client telnet, je me connecte sur un serveur quelconque, mais surtout je n'envoie rien... Quand j'arrête le serveur, le client découvre la déconnection quasi immédiatement, alors que le client n'envoie pas de données. Le serveur ne reçoit rien car je trace tout ce qui est reçu (même data OOB) ... Il semble donc que la detection ne se fasse pas sur un envoie ... Ou alors il y a une subtilité?

 
ton serveur fait un close sur le server socket ce qui a pour but de notifier le client.
 
Ton client a un bete socket donc si il se bare, le serveur n'est pas notifié

ok. mais justement, de quelle façon est notifié le client? C'est justement cela que j'aimerais savoir.
 

si, le serveur est toujours notifié dès lors qu'une socket est fermée du côté du client. Si on fait un select sur la socket serveur, alors est est marquée prête pour la lecture mais l'appel à recv retourne un nombre d'octets lus de 0.

 
 
tu crois ? Pkoi alors sur irc on voit des  
 
machin has quit irc (ping timeout)
 
(si ping timeout c que le client est pu la, si il est pu la et que le serveur l'a deco pour cause de ping timeout, c donc que le serveur ne savait pas que le client n t plus la, si tu me suis)

le ping timeout fait partie du protole irc. Quand une communication est down pdt un temps, le serveur envoie un ping request. Si un pong response n'est pas recu endéans les X sec, le serveur consdidère que le client s'est barré et les autres clients voient machin has quit IRC (ping timeout) stou

 
  le serveur est notifié que le client est down parce qu'il essaie d'envoyer un packet TCP et qu'il n'a pas de ack. Il n'y a rien qui est envoyé au serveur qd une socket est fermé (abruptement s'entend)

je ne sais pas comment cela se passe au niveau TCP, mais au niveau applicatif, il n'y a pas besoin d'essayer de lire ou d'envoyer des données depuis/vers la socket. Si ton process fait un select sur la socket, alors celle-ci est marquée prête pour la lecture mais l'appel à recv retourne un nombre d'octets lus de 0. Donc au niveau applicatif, le serveur n'a absolument rien besoin d'envoyer...
 
Par contre, côté client, ca reste le mystere...

 
rien compris a ce qu'a été dit, meme aux posts précédents...
 
sinon pour repondre a la question initiale (detecter qu'une connexion est en vie) : au niveau client ou serveur, faire un select en testant la writeability. si au bout du x-éme select, la socket n'est toujours pas writeable, bah on la considere comme morte.
 
exemple a la con fait en 5 min, ki autorise 10 sec avant de considerer une socket comme niquée.
 

je vais essayer comme cela...

 
cela ne fonctionne pas. la socket est toujours marquée comme writeable. Elle ne le sera plus soit après un close, soit après une erreur en écriture.
J'ai essayé d'utiliser certaines options des sockets comme par exemple SO_KEEPALIVE, mais rien n'y fait. Faut-il utiliser des options particulières?
 
Sous win32, j'ai vu que l'on peut être notifié de cet évènement lorsque l'on utilise la fonction WSAAsyncSelect en spécifiant que l'on veut être notifié des évènements de type FD_CLOSE, mais sous linux, cela ne me sert pas à grand chose...
 
bref, je cherche toujours la bonne info!!!

 
ca me rappelle qqchose, un post ou des gens qui disaient que sous linux, l'os marquait la socket comme invalide seulement apres un certain delai, fais une petite recherche, ca datait de moins de 2 mois je crois.
 
edit: voila :
http://forum.hardware.fr/forum2.ph [...] 86#t383387

 
je confirme que le comportement sous windows et linux est très différent

c pas tout à fait la même chose, quand même. Leur truc, ca ressemble à des sockets qui n'ont pas l'option SO_REUSEADDR, et ca n'a pas l'air spécifique à un OS ( c'est seulement la valeur de la tempo dont ils parlent qui est spécifique ).

ben je me permet de répondre en fait write envoie l'erreur EPIPE généré par le signal donc on ne peut detecter l'erreur uniquement en traitant le signal.
 
http://www.ucc.uconn.edu/cgi-bin/c [...] TS%20WRITE

moui, sauf que je voudrais détecter cette deconnexion sans avoir besoin d'ecrire continuellement. Et je persiste à croire que cela est possible. sous win32, la fonction WSAAsyncSelect notifie de la deconnexion du serveur même si le client n'envoie pas de données. D'ailleurs ouvre un client telnet sur un serveur quelconque, puis arrête le serveur: tu verras par toi même que le client détecte la déconnexion alors qu'il n'est pas en trai d'envoyer quoi que ce soit...

oui le client est toujours notifié de l'arret de l'autre partie via un signal SIGIO je crois (je ne connais les sockets que sous unix)