Quelles sont les causes du retard de réception udp?

Question

J'ai remarqué que lorsque j'envoie des paquets à intervalles réguliers à partir d'une socket udp, le premier paquet envoyé semble être retardé. Par exemple, si j'envoie les paquets toutes les 100 ms, je trouve le délai entre la réception des paquets à distribuer normalement avec une moyenne de 100 ms et l'écart type moyen de 4, sur mon réseau. Cependant, l'écart entre le temps de réception du premier et du second paquet est généralement de 10 à 40 ms - comme vous pouvez le voir, il s'agit clairement d'une différence statistiquement significative, et ma question est la suivante: quelle en est la cause? J'utilise la fonction sendto de C sous Linux. Quelqu'un a suggéré que le retard pourrait être provoqué par la résolution d'arp empêchant le paquet d'être envoyé jusqu'à ce que l'IP de destination ait été convertie en adresse mac - est-ce probable? Si je redémarre le programme d'envoi, le premier paquet prend encore trop de temps, et le retard est incohérent - 10 à 40 ms est une assez grande plage.

J'ai besoin de savoir pourquoi ce premier paquet prend trop de temps et comment contourner ce problème. Editer: Une analyse plus poussée avec pcap indique que le programme émetteur envoie les paquets au bon intervalle. Le problème doit être avec le récepteur qui utilise select() pour attendre une socket lisible, puis appelle recvfrom et imprime le paquet. Y a-t-il une sorte de mise en mémoire tampon que je ne connais peut-être pas?

Answer 1

Vous avez posé des questions sur les solutions de contournement. Une solution de contournement possible, si le temps de réception du paquet est important à savoir, consiste à définir l'option de socket SO_TIMESTAMP. Cela vous permettra d'obtenir l'heure à laquelle chaque paquet a été reçu par le noyau de destination - vous pouvez alors utiliser cette fois dans le traitement suivant plutôt que dans "l'heure actuelle". Vous pouvez également demander à l'expéditeur d'inclure un horodatage haute résolution dans le paquet qu'il envoie et de l'utiliser.

Answer 2

La spéculation ne nous mènera nulle part, allumez Wireshark et il vous dira tout ce que vous devez savoir.

Answer 3

Il est très probable que le temps requis pour la résolution d'adresse ARP. C'est le protocole qui résout les adresses MAC en adresses IP. Pour contourner ce problème, essayez d'utiliser des entrées statiques dans le cache ARP avec arp -s ip-address hw_address.

Answer 4

Est-ce sur un seul LAN? Si c'est le cas, il s'agit (probablement) d'une résolution ARP et/ou d'un nom d'hôte. Si c'est à travers un plus grand réseau, cela peut être n'importe quoi (bien que cela soit probablement lié à la recherche d'itinéraire et à la population de cache).

Answer 5

Je n'ai pas assez de «réputation» pour voter pour ce que je considère être la meilleure solution, alors je vais juste dire que le gars qui mentionne les messages ARP est très probablement juste. Je pense que les messages ARP ne devraient s'appliquer que sur le réseau local. Ils vont apparaître sur wireshark comme un "qui a 192.168.0.24?" par exemple ... et il y aura une réponse de n'importe quel hôte qui prétend avoir cette adresse IP. Le paquet initial envoyé via UDP à cette adresse doit obtenir une réponse ARP pour résoudre l'adresse IP en une adresse MAC Ethernet ... donc UDP, sur la surface peut sembler ne jamais devoir BLOQUER ... cependant ceci n'est vrai qu'une fois l'adresse ARP est résolue. Je ne suis pas sûr, mais je pense que si vous envoyez UDP à une adresse qui n'est pas sur le LAN, il ne devrait pas exiger un ARP ... à moins qu'il y ait un problème à trouver la passerelle principale.