Forcer la fermeture d'une connexion socket du coté serveur
4 réponses
Sivaller
Bonjour ;
Dans WinSock , pour que le serveur puisse ferme une connexion , il faut que
le client ferme lui aussi
sa connexion.
Comment forcer du serveur la fermeture d'une connexion (socket) client
?????????
car tant que le programme client n'a pas appeler la fonction closesocket ,
eh bien
la fonction closesocket du serveur est sans effet ;
J'ai essayez shutdown mais ça ne marche pas
info : je regarde la liste des connections avec le pare-feu Sygate
johann.d
"Sivaller" a écrit dans le message de news:45242cd0$0$5096$
Voici la preuve que Winsock n'est pas conforme !
Pas conforme à quoi ?
http://sivallerstatic.no-ip.org/connect.zip
Je clique sur Deconnecte au niveau du serveur et les connexions ne se ferment pas si je ne l'ai pas fermer depuis le client !
C'est un vieux marronier tu sais. Je crois que ça remonte à Al Gore, c'est quand il a inventé Internet il s'est trompé en considérant que les serveurs devaient survivre aux clients... J'ai bien l'impression que les Linuxiens sont sur la piste, quand j'étais jeune on avait trouvé le même bug dans Solaris, je crois qu'il y est toujours, maintenant Windows, mais où s'arrêtera-t-il ???
Bon sérieusement Google "TCP close socket bug" pour avoir quelques bonnes réponses. Voici une citation copiée d'un forum Linux (le premier listé par Google sur cette recherche) :
"
C'est une feature, pas un bug
La RFC décrivant TCP précise qu'apres la fermeture d'une socket, elle doit rester "inutilisable" pendant un certain temps (typiquement le round-trip time maxi défini pour une communication TCP), pour éviter qu'à une réouverture avec les mêmes ports, on se récupère des bouts de paquets de la connexion précédente qui étaient en transit dans les méandres d'internet.
"
-- johann.d
"Sivaller" <sivaller.ni@voila.fr> a écrit dans le message de
news:45242cd0$0$5096$ba4acef3@news.orange.fr...
Voici la preuve que Winsock n'est pas conforme !
Pas conforme à quoi ?
http://sivallerstatic.no-ip.org/connect.zip
Je clique sur Deconnecte au niveau du serveur et les connexions ne se
ferment pas si je ne l'ai
pas fermer depuis le client !
C'est un vieux marronier tu sais. Je crois que ça remonte à Al Gore, c'est
quand il a inventé Internet il s'est trompé en considérant que les serveurs
devaient survivre aux clients... J'ai bien l'impression que les Linuxiens
sont sur la piste, quand j'étais jeune on avait trouvé le même bug dans
Solaris, je crois qu'il y est toujours, maintenant Windows, mais où
s'arrêtera-t-il ???
Bon sérieusement Google "TCP close socket bug" pour avoir quelques bonnes
réponses. Voici une citation copiée d'un forum Linux (le premier listé par
Google sur cette recherche) :
"
C'est une feature, pas un bug
La RFC décrivant TCP précise qu'apres la fermeture d'une socket, elle doit
rester "inutilisable" pendant un certain temps (typiquement le round-trip
time maxi défini pour une communication TCP), pour éviter qu'à une
réouverture avec les mêmes ports, on se récupère des bouts de paquets de la
connexion précédente qui étaient en transit dans les méandres d'internet.
"Sivaller" a écrit dans le message de news:45242cd0$0$5096$
Voici la preuve que Winsock n'est pas conforme !
Pas conforme à quoi ?
http://sivallerstatic.no-ip.org/connect.zip
Je clique sur Deconnecte au niveau du serveur et les connexions ne se ferment pas si je ne l'ai pas fermer depuis le client !
C'est un vieux marronier tu sais. Je crois que ça remonte à Al Gore, c'est quand il a inventé Internet il s'est trompé en considérant que les serveurs devaient survivre aux clients... J'ai bien l'impression que les Linuxiens sont sur la piste, quand j'étais jeune on avait trouvé le même bug dans Solaris, je crois qu'il y est toujours, maintenant Windows, mais où s'arrêtera-t-il ???
Bon sérieusement Google "TCP close socket bug" pour avoir quelques bonnes réponses. Voici une citation copiée d'un forum Linux (le premier listé par Google sur cette recherche) :
"
C'est une feature, pas un bug
La RFC décrivant TCP précise qu'apres la fermeture d'une socket, elle doit rester "inutilisable" pendant un certain temps (typiquement le round-trip time maxi défini pour une communication TCP), pour éviter qu'à une réouverture avec les mêmes ports, on se récupère des bouts de paquets de la connexion précédente qui étaient en transit dans les méandres d'internet.
"
-- johann.d
Thierry
> C'est une feature, pas un bug
La RFC décrivant TCP précise qu'apres la fermeture d'une socket, elle doit rester "inutilisable" pendant un certain temps (typiquement le round-trip time maxi défini pour une communication TCP), pour éviter qu'à une réouverture avec les mêmes ports, on se récupère des bouts de paq uets de la connexion précédente qui étaient en transit dans les méandres d'i nternet.
C'est l'etat TIME WAIT affiche par TCPView, et dont la duree peut etre modifie via la BDR.
> C'est une feature, pas un bug
La RFC décrivant TCP précise qu'apres la fermeture d'une socket, elle doit
rester "inutilisable" pendant un certain temps (typiquement le round-trip
time maxi défini pour une communication TCP), pour éviter qu'à une
réouverture avec les mêmes ports, on se récupère des bouts de paq uets de la
connexion précédente qui étaient en transit dans les méandres d'i nternet.
C'est l'etat TIME WAIT affiche par TCPView, et dont la duree peut etre
modifie via la BDR.
La RFC décrivant TCP précise qu'apres la fermeture d'une socket, elle doit rester "inutilisable" pendant un certain temps (typiquement le round-trip time maxi défini pour une communication TCP), pour éviter qu'à une réouverture avec les mêmes ports, on se récupère des bouts de paq uets de la connexion précédente qui étaient en transit dans les méandres d'i nternet.
C'est l'etat TIME WAIT affiche par TCPView, et dont la duree peut etre modifie via la BDR.
