Ограничивает ли Linux передачу UDP моего приложения, и как я могу это увидеть?

В настоящее время я разрабатываю два приложения для работы по специальному «протоколу» потокового видео. В принципе:

• Сервер захватывает видеокадры с веб-камеры, разделяет их на части и отправляет эти части клиентам по UDP.
• Клиенты получают все части фреймов и обрабатывают все «переупорядочивание»: размещение частей в правильном порядке, сохранение новых фреймов «поверх» старых и так далее ... Вот где был реализован «протокол»: клиенты должны разбираться в получаемых видеоданных, чтобы можно было правильно их переупорядочить, и отображать правильный кадр.

Сам механизм работает отлично (признаю, после довольно долгой борьбы). Однако теперь, когда мои приложения работают, я обнаружил, что мой клиент изо всех сил пытается получить некоторые части фреймов. Клиент успешно получит детали для первого, скажем, п кадры, а потом просто ... подожди recvfrom. Я не буду беспокоить вас подробностями о всех приложениях, но вот некоторая статистика:

• Сервер захватывает кадр (38 016 байт) каждые 40 000 микросекунд (25 кадров в секунду).
• Каждый кадр делится на 24 части (38 016/24 = 1584 байта на часть).

Предположим, у нас всего 1 клиент. Со стороны сети это означает, что:

• Каждые 40 000 микросекунд сервер отправляет клиенту 24 буфера (sendto). Каждый буфер имеет длину 1584 байта. С другой стороны, клиент звонит recvfrom 24 раза.
• За секунду сервер может захватить 25 кадров. Это означает, что за 1 с он отправит клиенту 25 * 24 частей кадра. Это составляет 25 * 24 * 1584 = 950 400 байт в секунду).

Мы также предположим, что клиент всегда слушает, когда сервер отправляет. Теперь с такими ставками клиент сможет не отставать от 1 до 2 секунд. Пока приложение не зависнуть, клиент в конечном итоге начнет зависать recvfrom, как если бы сервер прекратил вещание.

Я добавил немного подробности своему серверу, чтобы убедиться, что он продолжает вещание, и это так. Через несколько секунд кажется, что сервер sendto звонки больше не доходят до клиента recvfrom звонки. Я проверил весь свой сетевой код, и, поскольку он довольно прост, в этом нет ничего плохого: сервер создает буфер, вызывает sendto, и начинает подготовку следующего буфера ... Клиент просто ждет буферов.

Поскольку я не могу найти объяснения в программировании, я начинаю верить, что что-то ... застряло в сети. Кажется, что-то где-то не позволяет моим UDP-пакетам достигать клиента через некоторое время. Теперь, когда UDP полностью свободен от управления, я не могу найти способ проверить транспорт моих буферов из моей программы.

Тем не менее, был бы у меня способ узнать, действительно ли система делает передать мои пакеты, или, если он в конечном итоге достигнет одного из своих пределов, и начнет их отбрасывать? Если да, то что это ограничение механизм, и есть ли способ настроить мою систему так, чтобы она позволяла моим приложениям работать с той скоростью, которую я их запрограммировал?

Поскольку мои приложения взаимодействуют через интерфейс обратной петли (сервер на 127.0.0.1:n), я подумал, что было бы неплохо добавить информацию об этом интерфейсе. Я использую систему GNU / Linux (ядро 3.13.0).

$ ifconfig lo
lo    Link encap:Local Loopback  
      inet addr:127.0.0.1  Mask:255.0.0.0
      inet6 addr: ::1/128 Scope:Host
      UP LOOPBACK RUNNING  MTU:65536  Metric:1
      RX packets:98821 errors:0 dropped:0 overruns:0 frame:0
      TX packets:98821 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:0 
      RX bytes:202639359 (202.6 MB)  TX bytes:202639359 (202.6 MB)