Comment tuer les connexions Windows Zombie TCP?

J'exécute le lien BeyondTV sur XP, me connectant à BeyondTV un hôte Vista. Le programme Link se bloque après environ 20 minutes, et je n'ai aucun correctif pour cela. Lorsque cela se produit, en utilisant tcpview, je vois que l'hôte a environ 200 connexions TCP zombie restantes de la connexion Link. Je ne peux pas les effacer, ils sont issus du même processus inexistant. Les connexions traînent jusqu'à ce que je redémarre l'hôte. Le redémarrage est le seul moyen que j'ai trouvé pour me reconnecter au-delà de Link. Je pense qu'il y a un bogue dans BeyondTV qui est à l'origine de cela, mais je ne peux obtenir aucune réponse sur leurs forums. Mais en tout cas, j'aimerais savoir s'il existe un moyen de tuer toutes ces connexions.

Edit: il s'agit en fait d'environ 3000 connexions WAIT_CLOSE qui s'accumulent après environ 40 minutes, et environ le client meurt. Si je ferme l'application serveur, toutes ces sockets s'affichent désormais comme appartenant à un processus - inexistant - dans tcpview. Compréhensible. Mais n'y a-t-il pas moyen de les fermer sans redémarrer?

Vous pouvez utiliser les Currports de Nirsoft pour surveiller et tuer les connexions.

Vous pouvez automatiser la suppression d'un modèle de connexion à l'aide d'AutoHotKey.

CLOSE_WAIT signifie que la connexion a été fermée à l'autre extrémité.

Évidemment, BeyondTV ne détecte pas cette condition et continue d'envoyer des données à l'application à l'autre bout. L'autre extrémité ne peut rien renvoyer via cette connexion, car elle a fermé la fin de la connexion.

La solution consiste à définir l' entrée TcpTimedWaitDelay dans

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\tcpip\Parameters

Cette entrée détermine le temps qui doit s'écouler avant que TCP puisse libérer une connexion fermée et réutiliser ses ressources. Cet intervalle entre la fermeture et la libération est appelé état TIME_WAIT ou état 2MSL. Pendant ce temps, la connexion peut être rouverte à un coût bien moindre pour le client et le serveur que l'établissement d'une nouvelle connexion.

Par défaut sur ma machine, cela contient la valeur -1, ce qui signifie que les connexions fermées ne sont jamais libérées, ce qui est exactement le comportement que vous observez.

Je vous suggère de définir la valeur de cette entrée dans la plage autorisée de 30 à 300 secondes. Je suppose que 300 secondes = 5 minutes est tout à fait suffisant pour votre cas, où il faut 40 minutes pour geler votre ordinateur.

Vous pouvez forcer Windows à forcer la fermeture de toutes les connexions TCP en 1) désactivant , puis 2) réactivant votre interface réseau. Si cela fonctionne, vous pouvez effectuer un script par lots des étapes à exécuter en cas de besoin.

J'ai fouillé pour trouver un moyen de le faire via la ligne de commande, à partir de l' netshutilitaire (ou similaire), mais je n'ai pas eu de chance jusqu'à présent.

Bien sûr, la meilleure façon de résoudre ce problème est de corriger l'application cassée. Assurez-vous que vous essayez la dernière version de l'application; continuez à mettre les développeurs sur écoute; si vous êtes déjà à la dernière version, essayez de localiser une ancienne version du programme.

Vous obtenez probablement ces sessions CLOSE_WAIT en raison du blocage du programme - je ne peux pas dire si vous les soupçonnez d'être la cause, alors je voulais juste que ce soit clair.

Je suppose qu'ils ne resteront pas éternellement; probablement seulement pendant 2 heures et 5 secondes. Cela peut sembler éternel, je sais. Vous pouvez essayer de régler le KeepAliveTime (nécessite probablement un redémarrage final) pour votre connexion réseau à quelque chose de petit, comme 5 minutes. Cela pourrait les aider à disparaître plus rapidement après le blocage de votre programme.

Ou si vous savez que vous pouvez exécuter le programme de manière fiable pendant, disons, 10 minutes à la fois, vous pouvez simplement le redémarrer périodiquement. Je ne sais pas si l'une de ces solutions est utile pour votre situation particulière; Je suis d'accord avec ~ quack que vous devriez abandonner la version problématique de l'application dès que possible.

Vérifiez si BeyondTV génère un autre processus qui maintient les connexions ouvertes. Process Explorer vous montrera si cela se produit.

Est-il possible qu'il y ait un problème de pare-feu? Il peut s'agir d'une connexion incomplète en cours de tentative et de nouvelle tentative.

Je désactiverais tous les pare-feu sur les deux machines, et s'il y a un routeur également son pare-feu interne.

Essayez le correctif WinSock XP.

http://www.snapfiles.com/get/winsockxpfix.html

Il supprime votre connexion et la réinitialise à sa valeur par défaut. Je garde toujours cela sur une clé USB lorsque tout le reste échoue.