Nous avons un système de communication client / serveur via la configuration UDP dans Windows. Le problème que nous sommes confrontés est que lorsque le débit se développe, les paquets sont tombés en baisse. Nous soupçonnons que cela est dû au tampon de réception UDP qui est interrogé en permanence, ce qui est bloqué que la mémoire tampon soit bloquée et dépose des paquets entrants. Est-il possible que la lecture de ce tampon provoque une perte de paquets entrants? Si oui, quelles sont les options pour corriger cela? Le système est écrit en C. S'il vous plaît laissez-moi savoir s'il est trop vague et je peux essayer de fournir plus d'informations. Merci!
6 Réponses :
Pas sûr de cela, mais sur Windows, il n'est pas possible de sonder la prise et de faire tomber un paquet. Windows recueille les paquets séparément de votre sondage et cela ne devrait causer aucune goutte.
Je suppose que vous utilisez Select () pour interroger la prise? Autant que je sache, je ne peux pas causer une goutte.
hmm..matanks pour la réponse, je suppose que nous devons rechercher davantage la cause de cela alors
Oui, la pile est autorisée à supprimer des paquets - silencieusement, même - lorsque ses tampons sont trop pleins. Cela fait partie de la nature de l'UDP, l'un des bits de fiabilité que vous abandonnez lorsque vous passez de TCP. Vous pouvez réinventer mal TCP - en ajoutant de nouvelles logiques, des paquets ACK, et vous pouvez passer à quelque chose d'entre eux comme SCTP .
Il existe des moyens d'augmenter la taille du tampon de la pile, mais il manque en grande partie le point. Si vous ne lisez pas assez vite pour garder un espace tampon disponible déjà, la réduction des tampons plus grandes ne fera que retirer le temps qu'il vous faut à court d'espace tampon. La solution appropriée consiste à apporter des tampons plus grands dans votre propre code et à déplacer les données des tampons de la pile dans le tampon de votre programme dès que possible, où il peut attendre d'être traité pour des temps de manière arbitraire.
Les paquets pourraient être perdus en raison d'une augmentation du trafic réseau non liée n'importe où le long de la route ou des tampons de réception complets. Pour atténuer cela, vous pouvez augmenter la taille de la mémoire tampon de réception dans WINSOCK.
Essentiellement, UDP est un protocole peu fiable en ce sens que la livraison de paquets n'est pas garantie et aucune erreur n'est renvoyée à l'expéditeur sur l'échec de la livraison. Si vous êtes inquiet pour la perte de paquets, il serait préférable de mettre en œuvre des paquets d'accusé de réception dans votre protocole de communication ou de le porter à un protocole plus fiable comme TCP. Il n'y a vraiment aucune autre manière vraiment fiable pour prévenir la perte de paquets UDP.
Est-il possible que la lecture de ce tampon entraînera des paquets entrants à supprimer?
Les paquets peuvent être laissés tomber s'ils arrivent plus vite que vous les lisez.
Si oui, quelles sont les options pour corriger cette situation?
Une option consiste à modifier le protocole réseau:. Utiliser TCP, ou mettre en œuvre une certaine reconnaissance + « contrôle de flux » en utilisant UDP
Sinon, vous devez comprendre pourquoi vous ne lisez pas rapide / assez souvent.
Si la CPU est 100% utilitized alors vous devez faire moins de travail par paquet ou obtenir un processeur plus rapide (ou l'utilisation multithreading et plus CPUs si vous n'êtes pas déjà).
Si la CPU est pas à 100%, alors peut-être ce qui se passe est:
- Vous avez lu un paquet
- Vous faites un travail qui prend x msec de temps réel, dont une partie est passé bloqué sur un autre E / S (de sorte que le CPU n'est pas occupé, mais il ne sert pas à lire un autre paquet)
- Au cours de ces x msec, arrivent un flot de paquets et certains sont lâchés
Un remède pour cela serait de changer le filetage.
Une autre possibilité consiste à faire plusieurs simultanée lit à partir de la douille (chacun de votre lit fournit une mémoire tampon dans laquelle un paquet UDP peut être reçu).
Une autre possibilité est de voir si l'option il y a une configuration (O / S spécifiques) pour augmenter le nombre de paquets UDP reçus qui la pile réseau est prêt à mémoire tampon jusqu'à ce que vous essayez de les lire.
La taille de la mémoire tampon de la prise par défaut dans les prises Windows est 8K, ou 8192 octets. Utilisez le SetSockopt Fonction Windows pour augmenter la taille de la taille de Le tampon (reportez-vous à l'option SO_RCVBUF).
Mais au-delà de cela, l'augmentation de la taille de votre tampon de réception ne retardera que le temps que les paquets sont à nouveau supprimés si vous ne lisez pas suffisamment les paquets.
Typiquement, vous voulez deux threads pour ce type de situation.
Le premier fil existe uniquement pour servir la prise. En d'autres termes, le seul but du fil est de lire un paquet à partir de la prise, de l'ajouter à une sorte de structure de données partagée correctement synchronisée, signalez qu'un paquet a été reçu, puis lisez le prochain paquet.
Le deuxième fil existe pour traiter les paquets reçus. Il se trouve au ralenti jusqu'à ce que le premier fil de fil signale qu'un paquet a été reçu. Il tire ensuite le paquet de la structure de données partagée correctement synchronisée et le traite. Il attend ensuite être signalé à nouveau.
comme test, essayez de faire court-circuiter le traitement complet de vos paquets et d'écrire un message à la console (ou à un fichier) chaque fois qu'un paquet a été reçu. Si vous pouvez le faire avec succès sans laisser tomber des paquets, enfoncez votre fonctionnalité dans un thread "récepteur" et un thread "Traitement" aidera.
première étape, augmentez la taille du tampon du récepteur, les fenêtres subordonnent à peu près toutes les demandes de taille raisonnables.
Si cela n'aide pas, votre code de consommation semble avoir des zones assez lentes. Je voudrais utiliser le threading, par exemple. avec Pthreads et utilise un motif de consommation de producteurs pour mettre le datagramme entrant dans une file d'attente sur un autre fil, puis consommez de là, vos appels de réception ne bloquent pas et le tampon ne fonctionne pas complètement
3ème étape, modifiez votre protocole de niveau d'application, permettez aux paquets par lots et aux paquets de lots de l'expéditeur de réduire les surcharges d'en-tête UDP de l'envoi de nombreux petits paquets.
4ème étape Vérifiez que votre réseau de réseau, vos commutateurs, etc. Vous pouvez vous donner une sortie détaillée sur leurs statistiques de trafic, les débordements de tampon, etc. - si cela est en cause, obtenez des commutateurs plus rapides ou éventuellement éventuellement basculer une erreur défectueuse
... juste FYI, je gère le trafic de multidiffusion UDP sur notre backend continuellement à AVG. ~ 30Mbit / sec avec des pics un 70Mbit / s et mon taux de chute est nu nil
Est la nature même de l'UDP pour déposer des paquets sous pression. Si vous souhaitez une livraison fiable, utilisez TCP.
En effet, UDP est autorisé à chuter, à réorganiser et à dupliquer vos paquets à tout moment; Il y a une "garantie", c'est que vous n'obtiendrez pas de paquets corrompus, mais en réalité, vous verrez cela aussi (la somme de contrôle IP est assez faible).
Remarqué la même chose. Mon serveur Linux transmet donc si vite que la mauvaise boîte Windows ne peut pas suivre ... pourtant la machine Windows n'est pas un entraîneur lent! Je vais essayer d'augmenter les tampons
Voir aussi Stackoverflow.com/Questtions/7968566/...