Ce qui peut provoquer TCP/IP pour déposer des paquets sans la suppression de la connexion?

J'ai une application basée sur le web et un client, tous deux écrits en Java. Pour ce que ça vaut, le client et le serveur sont à la fois sur Windows. Le client émet HTTP via Apache HttpClient. Le serveur bloque jusqu'à une minute et si aucun des messages sont arrivés pour le client dans la minute, le serveur renvoie HTTP 204 Aucun Contenu. Sinon, dès qu'un message est prêt pour le client, il est retourné avec le corps d'un HTTP 200 OK.

Voici ce qui m'a intrigué: par Intermittence pour un sous-ensemble spécifique de clients, toujours les clients avec manifestement feuilletée connexions réseau -- le client émet un GET, le serveur reçoit et traite les OBTENIR, mais le client est assis pour toujours. L'activation de journaux de débogage pour le client, je vois que HttpClient est toujours en attente de la première ligne de la réponse.

Il n'y a aucune Exception n'est levée sur le serveur, au moins rien de connecté n'importe où, pas par Tomcat, pas par ma webapp. Selon les journaux de débogage, il y a tous les signes que le serveur a répondu à la client. Toutefois, le client ne montre aucun signe d'avoir reçu quoi que ce soit. Le client se bloque indéfiniment dans HttpClient.execute. Cela devient évident après la fin de la session et le client prend des mesures qui provoque un autre Thread pour émettre un HTTP POST. Bien sûr, le POST échoue parce que la session a expiré. Dans certains cas, heures se sont écoulés entre la session expire et le client d'émettre un POST et découvrir ce fait. Pendant ce temps, executeMethod est toujours en attente de la réponse HTTP de la ligne.

Lorsque j'utilise WireShark pour voir ce qui se passe vraiment au fil de niveau, ce problème ne se produit pas. Qui est cet échec va se produire dans un délai de quelques heures pour des clients spécifiques, mais quand WireShark est en cours d'exécution aux deux extrémités, ces mêmes clients fonctionner du jour au lendemain, à 14 heures, sans un échec.

Quelqu'un d'autre a rencontré quelque chose comme cela? Ce qui dans le monde peut-il provoquer? J'ai pensé que le protocole TCP/IP de la garantie de livraison de paquets, même à travers à court terme du réseau de pépins. Si j'ai mis un SO_TIMEOUT et immédiatement réessayer la demande sur le délai d'attente, la nouvelle tentative réussit toujours. (Bien sûr, j'ai d'abord abandonner le temps de votre demande et la libération de la connexion afin de vous assurer qu'un nouveau socket sera utilisé.)

Pensées? Des idées? Est-il un paramètre TCP/IP disponible à Java ou un paramètre de registre de Windows, qui permettra à plus agressif TCP/IP tentatives sur la perte de paquets?

Des sons comme l'observation est en train de changer le resultat -> Heisenbug -> quelque chose de mal avec le filetage. Dans ce cas, il sonne comme quelqu'un va trop rapide (je mettrais mon argent sur HttpClient) et tout simplement des blocages à cause de cela. Il est possible que vous avez atteint un bug dans HttpClient lui-même, j'espère que d'autres peuvent être plus utiles et vous aider avec ce problème.

OriginalL'auteur Eddie | 2009-04-24

8

Êtes-vous absolument sûr que le serveur a été envoyée avec succès la réponse pour les clients qui semblent à l'échec? Par cela, je veux dire que le serveur a envoyé la réponse et le client est accusé de réception ed que la réponse du serveur. Vous devriez voir ceci à l'aide de wireshark sur le côté serveur. Si vous êtes sûr que ce n'a eu lieu sur le côté serveur et le client n'est toujours pas voir quoi que ce soit, vous avez besoin de regarder plus haut dans la chaîne à partir du serveur. Il n'existe aucun proxy/reverse proxy, serveurs ou NAT impliqués?

Le transport TCP est considéré comme un protocole fiable, mais il ne garantit pas la livraison. La pile TCP/IP de votre système d'exploitation va essayer assez difficile d'obtenir des paquets à l'autre extrémité à l'aide de TCP retransmissions. Vous devriez voir ces dans wireshark sur le côté serveur si ce qui se passe. Si vous voyez excessive retransmissions TCP, il est généralement une infrastructure réseau en question - c'est à dire de mauvais ou mal configuré matériel/interfaces. Les retransmissions TCP fonctionne très bien pour de courtes interruptions de réseau, mais fonctionne mal sur un réseau avec une longue interruption. C'est parce que la pile TCP/IP seulement envoyer les retransmissions après une minuterie expire. Ce minuteur généralement double après chaque échec de la retransmission. C'est par la conception afin d'éviter les inondations, déjà problématique en réseau avec les retransmissions. Comme vous pouvez l'imaginer, ce qui provoque généralement des applications de toutes sortes de problèmes de délai d'attente.

Selon la topologie de votre réseau, vous pouvez aussi avoir besoin de placer des sondes/wireshark/tcpdump à d'autres points intermédiaires dans le réseau. Ce sera probablement prendre un certain temps pour savoir où les paquets ont disparu.

Si j'étais vous, je voudrais garder le suivi avec wireshark sur tous les côtés jusqu'à ce que le problème se reproduit. Il est principalement probable. Mais, il semble que vous allez trouver est ce que vous l'avez déjà mentionné - feuilletée matériel. Si la fixation de l'feuilletée matériel est hors de question, vous devrez peut-être juste de construire en application supplémentaire au niveau des délais d'attente et les tentatives pour tenter de résoudre le problème dans le logiciel. Il semble que vous commencé à aller dans cette voie.

Tout ce que je peux dire à partir de la débogage en place quand il y a eu, c'est que mon application web croit qu'il a répondu. Je n'ai pas de permettre à tout le débogage dans Tomcat (6.x) elle-même pour voir si il croyait qu'il avait achevé la réponse. Il n'y avait pas de plaintes dans Tomcat, journal, ni d'Apache HTTPD, journal, ni mod_jk du journal. Feuilletée matériel est hors de mes mains ... dans certains cas, les gens vont sur l'internet public.
Il n'y a pas de substitut pour la dur de l'information. Wireshark vous permet de savoir qui parle et qui ne l'est pas.

OriginalL'auteur Gary
2

Oublier de rincer ou de fermer le socket sur le côté hôte peut par intermittence avoir cet effet pour de courtes réponses en fonction du temps qui pourrait être affectée par la présence de tout mécanisme de surveillance.

Surtout d'oublier de fermer quitter le socket balançant jusqu'à ce que GC devient autour de la récupération et des appels finalize().

OriginalL'auteur Lawrence Dol
2

Si vous utilisez long cours d'exécution, vous devriez délai d'attente sur le côté client, à deux fois le délai d'expiration du serveur, comme vous l'avez découvert.

Sur une connexion TCP où le client envoie un message et attend une réponse, si le serveur venait à se bloquer, et redémarrer (disons le point d'exemples), alors le client serait toujours en attente sur le support pour obtenir une réponse du Serveur mais le serveur n'est plus à l'écoute sur ce socket.

Le client ne peut découvrir la socket est fermée à la fin du serveur une fois qu'il envoie plus de données sur ce socket, et le serveur rejette ces nouvelles données, et ferme le socket.

C'est pourquoi vous devez avoir des délais d'attente côté client sur demande.

Mais que votre serveur n'est pas en panne, si le serveur a été multithread, et le filetage de la douille pour que le client fermé, mais à l'époque ( durée minutes), le client dispose d'une connectivité de la panne, puis la fin douille de poignée de main de mon être perdu, et que vous n'êtes pas d'envoyer plus de données sur le serveur depuis le client, votre client est une fois de plus laissée en suspens. Ce serait de cravate à votre desquamation de la connexion d'observation.

OriginalL'auteur Simeon Pilgrim
1

Je n'ai pas vu celui-ci en soi, mais j'ai vu des problèmes similaires avec de grandes datagrammes UDP provoquant la fragmentation IP qui conduisent à la congestion et finalement abandonnées trames Ethernet. Puisque c'est le protocole TCP/IP, je ne m'attends pas à de fragmentation d'IP pour être un grand problème puisque c'est une série basée sur le protocole.

Une chose que je remarque, c'est que TCP ne garantit pas la livraison! Il ne peut pas. Ce qu'elle n'est garantie que si vous envoyez octet Un suivie par byte B, vous ne recevrez jamais byte B avant d'avoir reçu octet Un.

Avec cela dit, je voudrais connecter l'ordinateur client et un système de surveillance de la machine à un concentrateur. Exécuter Wireshark sur la surveillance de la machine et vous devriez être en mesure de voir ce qui se passe. Je n'ai couru dans des problèmes liés à la fois gestion des espaces blancs entre les requêtes HTTP et incorrect HTTP tailles de segment. Les deux questions ont été en raison d'un écrit à la main HTTP pile donc, c'est seulement un problème si vous utilisez une pâte feuilletée de la pile.

OriginalL'auteur D.Shawley
0

Ces ordinateurs ont un virus/programme malveillant installé? À l'aide de wireshark installe winpcap (http://www.winpcap.org/) qui peut écraser les modifications les logiciels malveillants (ou le malware peut simplement détecter qu'il est surveillé et de ne pas tenter quoi que ce soit de louche).

Je n'avais pas considéré comme présent, mais il est à distance possible, bien sûr. Depuis que je ne vois pas cela sur les clients avec de la pâte feuilletée de la connexion réseau, j'ai jusqu'à présent supposé que le feuilletage lui-même est en quelque sorte la cause.
Malware est à distance possible, mais très improbable. Aller avec ce que vous savez déjà - feuilletage.

OriginalL'auteur BarrettJ
0

Si vous êtes de perdre des données, il est probablement dû à un bug logiciel, que ce soit dans la lecture ou l'écriture de la bibliothèque.

OriginalL'auteur Peter Lawrey

Vous devez vous connecter pour publier un commentaire.