Raw Socket Receive Buffer

Question

Nous testons actuellement une application Telecom sur IP. Nous ouvrons un Raw Socket et recevons les messages du côté distant (msgrate @ 750 + msgs/seconde taille approximative de 180 octets sans IP).

Sur le socket Raw se trouve une couche appelée SCTP (tout comme TCP) qui indique de temps en temps qu'il manque des paquets. Maintenant, nous exécutons Wireshark sur le nœud de réception et nous pouvons voir ce paquet dans Wireshark.

Il me semble que le tampon de réception de la socket est petit causant IP (?) Pour laisser tomber les messages. Cependant, les points d'accès IP (netstat -sv) n'indiquent AUCUN abandon de paquets. Nous avons essayé de mettre la file d'attente de réception de socket à 40000 sans aucun succès. J'apprécierais tous les pointeurs quant à l'option, le cas échéant, de la couche IP que nous devrions configurer ou est-il une option de socket spécifique que nous devons définir.

Answer 1

Merci pour vos entrées. Cependant, nous avons été en mesure de «résoudre» ce problème. Plus tôt, j'ai décrit comment nous lisions les messages. Une fois select sélectionné, nous exécutons une boucle (au nombre de messages bruts à lire qui était> 1 dans notre cas). 1) nous appelons ioctl (FIONREAD) pour trouver le nombre d'octets à lire; 2) lire que le nombre d'octets en appelant recvfrom 3) envoyer les octets jusqu'à l'utilisateur 4) aller en boucle à nouveau et appeler ioctl (FIONREAD), puis répétez les étapes

Cependant, au point 4, ioctl (FIONREAD) utiliser pour retourner 0. Notre code avait un contrôle défensif. Il attendait, un 0 octets de ioctl (FIONREAD) signifie que l'expéditeur a envoyé un en-tête IP avec 0 charge utile. Par conséquent, il faut appeler recvfrom (octets à lire = 0) pour vider l'en-tête IP de peur que le select ne se redéfinisse à ce sujet. Ioctl (FIONREAD) renvoie 0 comme nombre d'octets à lire À l'instant t1, recvfrom (octets à lire = 0) est appelé. Parfois, entre t0 et t1, les données réelles sont mises en file d'attente dans la file d'attente de réception de socket et utilisées pour être supprimées lorsque nous appelons recvFrom (bytes = 0).

Paramètre, le nombre de rawMsgsToRead = 1 a "résolu" ce problème. Cependant, je suppose que cela aura un impact sur notre performance.Est-ce que leur appel ioctl peut différencier les octets de la file d'attente de 0 et l'en-tête IP avec la charge utile 0

Answer 2

J'ai quelques questions et quelques points à considérer. 1) Quelle implémentation de SCTP utilisez-vous et sur quel système d'exploitation. Certaines implémentations SCTP sont plus robustes que d'autres. 2) SCTP reconnaît-il négativement les paquets abandonnés? Rechercher un acks d'écart dans wireshark. 3) Et où vous voyez les paquets abandonnés dans wireshark êtes-vous sûr que ce ne sont pas des retransmissions? 4) Où dans le système est la surveillance de wirehark? Si ce n'est pas sur le même fil que votre application, il se peut que des messages n'apparaissent pas dans votre application. 5) Quelle est exactement l'indication de SCTP?

Si vous pensez que le tampon rx du socket IP est en train de déborder, vous pouvez envisager de réduire la taille de la fenêtre SCTP RX; ceci est souvent configurable dans les piles sctp. La fenêtre Rx limite la quantité de données pouvant être en attente d'accusé de réception et limite par conséquent la quantité de données qui pourrait se trouver dans le tampon IP. Vous pouvez également essayer d'augmenter la priorité de votre tâche SCTP afin qu'elle lise plus rapidement les messages hors des tampons IP (cela peut être la chose la plus facile à essayer et, selon moi, une bonne chose à faire).

Cordialement