Problème avec paquet retards sur adaptateur réalimentation TCP / IP de Windows 7 (ou bug dans le logiciel?)

Question

Nous avons une application client et le serveur test actuellement sur la même machine Windows 7 64 bits. Ils sont tous deux écrits en C # et en utilisant P / Invoke pour appeler aux bibliothèques Winsock2.

L'application fonctionne bien dans l'ensemble w / o des erreurs. Et le temps d'attente pour chaque "hop" sur les moyennes TCP / IP environ 350 microsecondes.

Cependant, à l'occasion, il y a des délais très longs de plus de 40 à 50 ms avant de recevoir des paquets et puis tout à coup, ils arrivent tous.

Les efforts pour diagnostiquer jusqu'à présent:

1. Au cours de ces retards de réception de données, le serveur continue à enregistrer qu'il est l'envoi de paquets. Il est mis à envoyer des paquets de test tous les 1 ms dont il fera pour 15 ou 20 et jusqu'à 50 ms parfois avant que le client reçoit un d'entre eux.

2. Le tcpdump a été utilisé pour les paquets de renifler sur l'adaptateur de rebouclage et montre que pendant cette période de latence, il y a le trafic du port du serveur (6488) au port client (61743) comme d'habitude.

3. Le client appelle la sélection () appel winsock2 dans une boucle si l'enregistrement par l'intermédiaire d'un compteur avant les émissions d'appel de sélection () qu'il a le descripteur de fichier correct. Et bien sûr, ce travaux avant et après le délai très bien.

4. En outre l'exploitation forestière immédiatement après les spectacles d'appel select () que le fd n'est pas présent - ce qui signifie qu'une lecture sur le socket bloque. Toutefois, pendant les périodes de transmission w / o les retards, les spectacles de l'exploitation forestière, il fonctionne comme prévu de sorte que select () retourne le fd de la douille pour faire une lecture non bloquante.

En bref, l'adaptateur de rebouclage semble tenir ces paquets quelque part pendant un long moment avant de finalement les livrer au côté réception.

Les autres idées ou une solution?

Quelques réflexions sont il est souvent affirmé que les E / S chevauchée fonctionne mieux sur Windows, mais qui semble seule question pour l'évolutivité si vous avez besoin d'écouter plus de 64 prises.

Peut-être que le passage à chevauché fera l'affaire? Nous voulons éviter que cela augmentera la date limite du projet et le budget. Cela devrait fonctionner avec select () très bien.

En outre, peut-il que le processus ou thread dans Windows qui gère le rebouclage obtient contexte commutées ou quelque chose et, si oui, est-il possible de le configurer pour éviter ces retards?

Edit: La bonne réponse était de faire en sorte que l'algorithme Nagle a été désactivé. Nous avons pensé qu'il était invalide, mais qui est où le bug a été trouvé - dans notre mise en œuvre en interne de SetSocketOption () nous avons utilisé GetSocketOption () pour vérifier. Donc, il s'avère que vous devez définir NoDelay avant de connecter ou se lier à une prise ou bien elle échoue silencieusement d'avoir un quelconque effet.

Un grand merci à Fun Mun Pieng pour la réponse correcte !!!

Answer 1

Je soupçonne que cela peut être dû à la algorithme Nagle . Les désactive de code suivant: il

socket.SetSocketOption(SocketOptionLevel.Tcp, SocketOptionName.NoDelay, true);