Что вызывает задержку приема удп? - PullRequest
3 голосов
/ 20 декабря 2010

Я заметил, что когда я отправляю пакеты с равными интервалами из сокета udp, первый отправленный пакет, кажется, задерживается.Например, если я отправляю пакеты каждые 100 мс, я нахожу, что задержка между приемом пакетов обычно распределяется со средним значением 100 мс и средним стандартным отклонением 4 в моей сети.Тем не менее, промежуток между временем приема первого и второго пакетов обычно составляет от 10 до 40 мс - как вы можете видеть, это явно статистически значимое различие, и поэтому мой вопрос, что его вызывает?

Я использую функцию sendto из C на Linux.Кто-то предположил, что задержка может быть вызвана разрешением arp, препятствующим отправке пакета до тех пор, пока IP-адрес назначения не будет преобразован в MAC-адрес - возможно ли это?Если я перезапущу отправляющую программу, первый пакет снова займет слишком много времени, и задержка будет непостоянной - от 10 до 40 мс - довольно большой диапазон.

Мне нужно выяснить, почему этот первый пакет занимает слишком много времени.и как обойти это.

Редактировать: Дальнейший анализ с помощью pcap показывает, что отправляющая программа отправляет пакеты с нужным интервалом.Проблема должна быть с получателем, который использует select () для ожидания читаемого сокета, затем вызывает recvfrom и печатает пакет.Есть ли там какая-то буферизация, о которой я не знаю?

Ответы [ 5 ]

2 голосов
/ 20 декабря 2010

Скорее всего, это время, необходимое для разрешения адреса ARP .Это протокол, который разрешает MAC-адреса в IP-адреса.

Чтобы обойти эту проблему, попробуйте использовать статические записи в кэше arp с arp -s ip-address hw_address.

1 голос
/ 20 декабря 2010

Спекуляция ни к чему нас не приведет, запустит Wireshark и она расскажет вам все, что вам нужно знать.

0 голосов
/ 30 сентября 2013

У меня недостаточно «репутации», чтобы проголосовать за то, что я считаю лучшим решением, поэтому я просто скажу, что парень, который упоминает сообщения ARP, скорее всего, прав.Я думаю, что сообщения ARP должны применяться только на локальной сети.Они будут отображаться на Wireshark как "у кого есть 192.168.0.24?"например ... и затем будет ответ от любого хоста, который утверждает, что имеет этот IP-адрес.Первоначальный пакет, отправленный через UDP на этот адрес, должен получить ответ ARP, чтобы преобразовать IP-адрес в MAC-адрес Ethernet ... так что на поверхности UDP может показаться, что он никогда не должен блокироваться ... однако это верно только один разадрес ARP разрешен.Я не уверен, но я думаю, что если вы отправляете UDP на адрес, который не находится в локальной сети, он не должен требовать ARP ..., если нет проблемы с поиском основного шлюза.

0 голосов
/ 21 декабря 2010

Вы спрашивали об обходных путях. Одним из возможных путей решения этой проблемы, если важно знать время приема пакета, является установка опции сокета SO_TIMESTAMP. Это позволит вам получить время, когда каждый пакет был получен ядром назначения - вы можете использовать это время в последующей обработке, а не «текущее время».

В качестве альтернативы, вы можете сделать так, чтобы отправитель включил метку времени высокого разрешения в отправляемый пакет и использовал их.

0 голосов
/ 20 декабря 2010

Это в одной локальной сети? Если так, это (вероятно) до разрешения ARP и / или имени хоста. Если это сеть большего размера, это может быть что угодно (хотя, вероятно, это связано с поиском маршрутов и заполнением кэша).

...