Was verursacht UDP-Empfangsverzögerung?

Question

Ich habe bemerkt, dass, wenn ich Pakete in gleichen Intervallen von einem Udp-Socket senden, das erste Paket gesendet wird, scheint verzögert zu sein. Wenn ich zum Beispiel die Pakete alle 100 ms sende, finde ich die Verzögerung zwischen dem Empfang der normal zu verteilenden Pakete mit mittleren 100 ms und der durchschnittlichen Standardabweichung von 4 in meinem Netzwerk. Der Abstand zwischen der Empfangszeit für das erste und das zweite Paket beträgt jedoch normalerweise etwa 10 bis 40 ms - wie Sie sehen können, ist dies eindeutig ein statistisch signifikanter Unterschied, und meine Frage ist, was verursacht es?

Ich verwende die sendto-Funktion von C auf Linux. Jemand schlug vor, dass die Verzögerung durch eine ARP-Auflösung verursacht werden könnte, die verhindert, dass das Paket gesendet wird, bis die Ziel-IP in eine MAC-Adresse konvertiert wurde - ist das wahrscheinlich? Wenn ich das sendende Programm neu starte, dauert das erste Paket wieder zu lange, und die Verzögerung ist inkonsistent - 10 bis 40 ms sind ein ziemlich großer Bereich.

Ich muss herausfinden, warum dieses erste Paket zu lange dauert, und wie man es umgehen kann.

Edit: Weitere Analyse mit pcap zeigt an, dass das sendende Programm die Pakete im richtigen Intervall sendet. Das Problem muss beim Empfänger liegen, der mit select() auf einen lesbaren Socket wartet, dann recvfrom aufruft und das Paket druckt. Gibt es eine Art Pufferung, von der ich vielleicht nichts weiß?

Answer 1

Sie haben nach Workarounds gefragt. Eine mögliche Problemumgehung, wenn die Empfangszeit des Pakets wichtig ist, ist das Festlegen der Socket-Option SO_TIMESTAMP. Dadurch erhalten Sie die Zeit, die jedes Paket vom Zielkernel empfangen wurde - Sie können diese Zeit dann in der nachfolgenden Verarbeitung und nicht in der "aktuellen Zeit" verwenden.

Alternativ könnte der Absender einen hoch aufgelösten Zeitstempel in das Paket aufnehmen, das er sendet, und diese verwenden.

Answer 2

Spekulation wird uns nirgendwohin bringen, feuern Wireshark und es wird Ihnen alles erzählen, was Sie wissen müssen.

Answer 3

Es ist höchstwahrscheinlich die Zeit, die für die Adressauflösung ARP erforderlich ist. Dies ist das Protokoll, das MAC-Adressen in IP-Adressen auflöst.

Um dies zu umgehen, verwenden Sie statische Einträge im ARP-Cache mit arp -s ip-address hw_address.

Answer 4

Ist dies in einem einzelnen LAN? Wenn dies der Fall ist, liegt es wahrscheinlich an der ARP- und/oder Hostnamen-Auflösung. Wenn es sich um ein größeres Netzwerk handelt, kann es alles sein (obwohl es wahrscheinlich mit der Routensuche und der Cache-Population zusammenhängt).

Answer 5

Ich habe nicht genug "Reputation", um zu stimmen, was ich für die beste Lösung halte, also sage ich nur, dass der Typ, der ARP-Nachrichten erwähnt, höchstwahrscheinlich recht hat. Ich denke, die ARP-Nachrichten sollten nur für das LAN gelten. Sie werden auf Wireshark als "wer hat 192.168.0.24?" zum Beispiel ... und dann wird es eine Antwort von jedem Host geben, der behauptet, diese IP-Adresse zu haben. Das anfängliche Paket, das über UDP an diese Adresse gesendet wird, muss eine ARP-Antwort erhalten, um die IP-Adresse in eine Ethernet-MAC-Adresse aufzulösen ... so UDP, auf der Oberfläche mag es so aussehen, als sollte es niemals BLOCKEN ... dies ist jedoch nur einmal der Fall Die ARP-Adresse ist aufgelöst. Ich bin mir nicht sicher, aber ich denke, wenn Sie UDP an eine Adresse senden, die nicht im LAN ist, sollte es kein ARP erfordern ... es sei denn, es gibt ein Problem, das primäre Gateway zu finden.