Как реализовать RFC 3393 (вариация задержки пакета Ipdv) в C?

Question

Я создаю приложение Ethernet, в котором я буду отправлять пакеты с одной стороны и получать их с другой стороны.Я хочу рассчитать задержку пакетов на стороне получателя, как в RFC 3393.Поэтому мне нужно поместить временные метки в пакет на стороне отправителя, а затем получить временные метки на стороне получателя, как только я получу пакет.Вычитая значения, я получаю разницу во временных метках, а затем вычитая это значение с последующей разницей, я получаю задержку ipdv в одну сторону. Оба часа не синхронизированы. Поэтому любая помощь очень ценится.Спасибо.

Answer 1

RFC 3393 предназначен для измерения дисперсия в задержке пакета, а не для измерения самой задержки.

Приведу пример:вы пишете приложение для потоковой передачи видео.Вы хотите буферизовать как можно меньше видеоданных (чтобы видео начало воспроизводиться как можно скорее).Допустим, данные всегда всегда всегда Переход от машины А к машине Б занимает 20 мс.В этом случае (и если предположить, что машина А может отправлять видеоданные с такой скоростью, с какой требуется воспроизведение), вам вообще не нужен буфер.Как только вы получите первый кадр, вы можете начать играть, зная, что к тому времени, когда понадобится следующий кадр, он уже будет доставлен (поскольку для прибытия данных всегда требуется ровно 20 мс, а машина А отправляет не менее так же быстро, как вы играете).

Это работает независимо от того, насколько велики эти 20 мс, если они всегда одинаковы.Это может быть 1000 мс — первый кадр приходит за 1000 мс, но вы все равно можете начать играть, как только он прибудет, потому что следующий кадр также займет 1000 мс и был отправлен сразу за первым кадром — другими словами, он уже на своем путь и будет здесь на мгновение.Очевидно, что реальный мир не такой.

Возьмите другую крайность:в большинстве случаев данные поступают за 20 мс.За исключением случаев, когда это занимает 5000 мс.Если у вас нет буфера и задержка кадров с 1 по 50 составляет 20 мс, то вы без проблем сможете воспроизвести первые 50 кадров.Затем для появления кадра 51 требуется 5000 мс, и вы остаетесь без каких-либо видеоданных в течение 5000 мс.Пользователь заходит на другой сайт, чтобы посмотреть видео с милыми котиками.Что вам действительно нужно, так это буфер данных емкостью 5000 мс — тогда все будет в порядке.

Длинный пример, краткая суть:тебе не интересно, что абсолютный задержка пакетов, вас интересует, что дисперсия в этой задержке - настолько велик должен быть ваш буфер.

Чтобы измерить абсолютный задержки, вам придется синхронизировать часы на обеих машинах.Машина А отправит пакет с отметкой времени 12337849227. 28 и когда это прибыло на машину Б в момент 12337849227 48, вы бы знали, что пакету потребовалось 20 мс, чтобы добраться туда.

Но поскольку вас интересует дисперсия, вам нужно (как описано в RFC 3393) несколько пакетов от машины A.Машина А отправляет пакет 1 с отметкой времени 1233784922. 72 8, затем через 10 мс отправляет пакет 2 с отметкой времени 1233784922. 73 8, затем через 10 мс отправляет пакет 3 с отметкой времени 1233784922. 74 8.

Машина Б получает пакет 1 с временной меткой 1233784922. 12 8.Односторонняя задержка между машиной A и машиной B в этом случае (с точки зрения машины B) составила -600 мс.Это, очевидно, полная чушь, но нам плевать.Машина Б получает пакет 2 с временной меткой 1233784922. 15 8.Односторонняя задержка составила -580 мс.Машина B получает пакет 3 с временной меткой 1233784922. 16 8.Односторонняя задержка снова составила -580 мс.

Как и выше, нас не волнует, какова абсолютная задержка, поэтому нас даже не волнует, будет ли она отрицательной, тремя часами или чем-то еще.Что нас волнует, так это то, чтобы величина задержки менялась на 20 мс.Итак, вам нужен буфер данных размером 20 мс.

Обратите внимание, что здесь я полностью умалчиваю о проблеме дрейфа часов (то есть, часы на машинах A и B работают с немного разной скоростью, так что, например, время машины A идет вперед со скоростью 1,00001 секунды за каждую секунду, которая на самом деле прошедший).Хотя это и приводит к неточности измерений, практический эффект от этого вряд ли станет проблемой в большинстве приложений.