Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
1526 connectés 

  FORUM HardWare.fr
  Programmation
  C++

  [socket TCP] gestion de la deconnexion d1 client telnet

 



 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

[socket TCP] gestion de la deconnexion d1 client telnet

n°412745
SoWhatIn22
Posté le 02-06-2003 à 13:29:02  profilanswer
 

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.
 
 

mood
Publicité
Posté le 02-06-2003 à 13:29:02  profilanswer
 

n°412778
darklord
You're welcome
Posté le 02-06-2003 à 13:40:34  profilanswer
 

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


---------------
Just because you feel good does not make you right
n°412965
SoWhatIn22
Posté le 02-06-2003 à 14:12:47  profilanswer
 

DarkLord a écrit :

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


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

n°412972
darklord
You're welcome
Posté le 02-06-2003 à 14:15:02  profilanswer
 

sowhatin22 a écrit :


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é


---------------
Just because you feel good does not make you right
n°413038
SoWhatIn22
Posté le 02-06-2003 à 14:36:39  profilanswer
 

DarkLord a écrit :


ton serveur fait un close sur le server socket ce qui a pour but de notifier le client.


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

DarkLord a écrit :


Ton client a un bete socket donc si il se bare, le serveur n'est pas notifié


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.

n°413043
chrisbk
-
Posté le 02-06-2003 à 14:38:00  profilanswer
 

Citation :

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)

n°413052
darklord
You're welcome
Posté le 02-06-2003 à 14:40:13  profilanswer
 

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 [:spamafote]


Message édité par darklord le 02-06-2003 à 14:40:23

---------------
Just because you feel good does not make you right
n°413059
darklord
You're welcome
Posté le 02-06-2003 à 14:42:19  profilanswer
 

sowhatin22 a écrit :


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.


 
 :non: 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)


---------------
Just because you feel good does not make you right
n°413094
SoWhatIn22
Posté le 02-06-2003 à 14:52:16  profilanswer
 

DarkLord a écrit :


 
 :non: 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...

n°413153
Konar
Posté le 02-06-2003 à 15:19:37  profilanswer
 

sowhatin22 a écrit :


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


 
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.
 

Code :
  1. int Timeout = 10;
  2. struct timeval tv;
  3. tv.tv_sec = 1;
  4. tv.tv_usec = 0;
  5. while (Timeout-- > 0)
  6. {
  7. fd_set write_set
  8. FD_ZERO(&write_set);
  9. FD_SET(Send->Socket, &write_set);
  10. int err = select(1, NULL, &write_set, NULL, &tv);
  11. switch (err)
  12. {
  13.  case 0:
  14.   // Waiting
  15.   break;
  16.  case SOCKET_ERROR:
  17.   // Error
  18.   return false;
  19.  default:
  20.   if (FD_ISSET(Send->Socket, &write_set))
  21.   {
  22.    // Socket is writeable
  23.    return true;
  24.   }
  25. }
  26. }

mood
Publicité
Posté le 02-06-2003 à 15:19:37  profilanswer
 

n°413260
SoWhatIn22
Posté le 02-06-2003 à 16:19:21  profilanswer
 

je vais essayer comme cela...

n°413902
SoWhatIn22
Posté le 03-06-2003 à 08:42:28  profilanswer
 

Konar a écrit :


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.


 
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!!!

n°414014
Konar
Posté le 03-06-2003 à 10:07:04  profilanswer
 

sowhatin22 a écrit :


 
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


Message édité par Konar le 03-06-2003 à 10:10:25
n°414030
darklord
You're welcome
Posté le 03-06-2003 à 10:21:28  profilanswer
 

Konar a écrit :


 
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 :/


---------------
Just because you feel good does not make you right
n°414062
SoWhatIn22
Posté le 03-06-2003 à 10:46:14  profilanswer
 

Konar a écrit :


 
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.


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

n°414702
fabriceMer​c
Posté le 03-06-2003 à 16:21:23  profilanswer
 

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


---------------
L'été il fait bo
n°414784
SoWhatIn22
Posté le 03-06-2003 à 17:24:40  profilanswer
 

fabriceMerc a écrit :

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

n°415781
fabriceMer​c
Posté le 04-06-2003 à 10:31:23  profilanswer
 

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)


---------------
L'été il fait bo

Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Programmation
  C++

  [socket TCP] gestion de la deconnexion d1 client telnet

 

Sujets relatifs
[PHP] gestion des accents sous Linux[JAVA][RESEAU]Problèmes sockets TCP/IP
[C] gestion des nombres aléatoires[Perl] Utiliser le module Net::Telnet sans l'avoir installé
[perl] Exécuter un telnet dans un cgi perl[Java]Gestion de sources...
2 questions : gestion des exceptions et paramètres des fonctionsprobleme avec la gestion d'evenement dans une balise div
Lire les données d'un fichier sur le PC clientGestion Clients
Plus de sujets relatifs à : [socket TCP] gestion de la deconnexion d1 client telnet


Copyright © 1997-2018 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR