Доброе время суток, уважаемые. Заранее извиняюсь,что повторяю уже ранее заданный вопрос, но я так и не нашел объяснения.
Пишу графическое приложение реального времени, работающее на нескольких машинах. Приложение-мастер (сервер) получает по TCP-сокетам данные с частотой примерно 100 Гц по 100 — 150 байт в посылке и должно синхронно ретранслировать данные еще на ряд клиентских машин. Ретрансляция реализована на UDP с помощью multicast. Все нормально работает и ничего не теряется (проверено), но иногда на сервер поступают дополнительные данные, несколько посылок тоже по 100 – 150 байт, которые тоже должны быть ретранслированы клиентам. Так вот в процессе ретрансляции этих посылок часть из них теряется. Заметив такое поведение решил написать отдельный тест и набрел на проблему, подобные которой неоднократно всплывали на этом форуме, но для себя я ответов так и не нашел. А проблема – потеря пакетов в зависимости от занятости приложения или нагрузки процессора.
Проиллюстрирую на примере тестового приложения. Приложение создает два блокирующих UDP сокета (через socket()), один на чтение, другой на запись, запускает поток, в котором для сокета чтения в цикле выполняется recvfrom(), в то время как, в основном потоке для сокета записи в цикле выполняется посылка данных с помощью sendto() (5 байт). На другой машине это же приложение принимает посылки и отправляет обратно подтверждение доставки (5 байт, все посылки нумеруются). Приложение продолжает непрерывно посылать посылки с одним и тем же номером пока не придет подтверждение доставки этой посылки, после чего приложение переходит к отправке следующей посылки и т.д. Если в основном потоке, который шлет посылки после отправки поставить задержку от 6 мс и более, через вызов Sleep(), то все работает чудесно. Если же задержка меньше 6 мс то посылки, примерно каждая 10-ая или около того, начинают теряться (на том конце приложение их не получает и, соответственно, не отправляет подтверждение). Все это происходит при том, что sendto() не возвращает ошибок, а говорит, что все байты посланы. При полном отсутствии задержки в цикле отправки посылок сообщения отправляются, но на другом конце не получаются вообще. Вот такая история. О железе: Dual Core Athlon 64 4800+ CPU, 2 Gb RAM, 1 Gb LAN. ОС Windows XP PRO SP2, сеть более менее в порядке, так как машины включены в отдельный свич, провода метровой длины и больше там никого нет. Сами понимаете, что при таких размерах посылок сеть не грузится более чем на доли процента. Пробовал менять размеры буферов чтения и записи, проверял максимальный размер посылки (SO_RCVBUF, SO_SNDBUF, SO_MAX_MSG_SIZE) – серьезного влияния не оказывают.
Складывается ощущение, что физически пакеты передаются, но не обрабатываются операционной системой. Большая просьба к специалистам, подскажите в чем причина и, если кто знает, то как обойти проблему.

Здравствуйте, black_jesus, Вы писали:

_>Доброе время суток, уважаемые. Заранее извиняюсь,что повторяю уже ранее заданный вопрос, но я так и не нашел объяснения.
_>Пишу графическое приложение реального времени, работающее на нескольких машинах. Приложение-мастер (сервер) получает по TCP-сокетам данные с частотой примерно 100 Гц по 100 — 150 байт в посылке и должно синхронно ретранслировать данные еще на ряд клиентских машин. Ретрансляция реализована на UDP с помощью multicast. Все нормально работает и ничего не теряется (проверено), но иногда на сервер поступают дополнительные данные, несколько посылок тоже по 100 – 150 байт, которые тоже должны быть ретранслированы клиентам. Так вот в процессе ретрансляции этих посылок часть из них теряется. Заметив такое поведение решил написать отдельный тест и набрел на проблему, подобные которой неоднократно всплывали на этом форуме, но для себя я ответов так и не нашел. А проблема – потеря пакетов в зависимости от занятости приложения или нагрузки процессора.

Я эти проблемы решаю по-лоховски — задираю приоритет принимающего потока на повыше (насколько — тут смотри сам, мне и THREAD_PRIORITY_ABOVE_NORMAL хватает), проблема решается на гораздо более тухлом железе.

black_jesus wrote:
>
> Доброе время суток, уважаемые. Заранее извиняюсь,что повторяю уже ранее
> заданный вопрос, но я так и не нашел объяснения.
> Пишу графическое приложение реального времени, работающее на нескольких
> машинах. Приложение-мастер (сервер) получает по TCP-сокетам данные с
> частотой примерно 100 Гц по 100 — 150 байт в посылке и должно синхронно
> ретранслировать данные еще на ряд клиентских машин. Ретрансляция
> реализована на UDP с помощью multicast. Все нормально работает и ничего
> не теряется (проверено), но иногда на сервер поступают дополнительные
> данные, несколько посылок тоже по 100 – 150 байт, которые тоже должны
> быть ретранслированы клиентам. Так вот в процессе ретрансляции этих
> посылок часть из них теряется. Заметив такое поведение решил написать
. . . .
> размеры буферов чтения и записи, проверял максимальный размер посылки
> (SO_RCVBUF, SO_SNDBUF, SO_MAX_MSG_SIZE) – серьезного влияния не оказывают.

Операционная система какая? Раз не указана, я предполагаю, что Windows.

Мне сильно помогло в похожей ситуации поставить SO_RCVBUF в 64К. По
дефолту он какой-то уж до неприличия маленький.

Еще имеет смысл поднять приоритет того потока, который принимает пакеты.
Иначе, при наличии других активных приложений, он может терять CPU на
десятки, а иногда и сотни миллисекунд.

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

За это время посылатель вполне может успеть отправить несколько пакетов,
если не вставлять задержки.

On Tue, 15 Nov 2005 20:18:43 -0000, black_jesus <36450@users.rsdn.ru> wrote:

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

[]

> Складывается ощущение, что физически пакеты передаются, но не обрабатываются операционной системой. Большая просьба к специалистам, подскажите в чем причина и, если кто знает, то как обойти проблему.

Тут упоминалось, что проблема с потерей UDP пакетов свойственна виндозе. Попробуй линукс или фрю.

--
Maxim Yegorushkin

Здравствуйте, aik, Вы писали:

aik>Я эти проблемы решаю по-лоховски — задираю приоритет принимающего потока на повыше (насколько — тут смотри сам, мне и THREAD_PRIORITY_ABOVE_NORMAL хватает), проблема решается на гораздо более тухлом железе.

Пробовал, не помогает. Этого собственно и следовало ожидать. Так как пакеты, судя по всему, не уходят с моей машины, и им до приоритета потока чтения на другом конце как до лампочки.

Здравствуйте, Pzz, Вы писали:


Pzz>Операционная система какая? Раз не указана, я предполагаю, что Windows.

Я же писал, Windows XP Pro SP2

Pzz>Мне сильно помогло в похожей ситуации поставить SO_RCVBUF в 64К. По
Pzz>дефолту он какой-то уж до неприличия маленький.

Пробовал, не помогает. Причем я где-то читал, что UDP все равно больше чем 8192 не отправляет

Pzz>Еще имеет смысл поднять приоритет того потока, который принимает пакеты.
Pzz>Иначе, при наличии других активных приложений, он может терять CPU на
Pzz>десятки, а иногда и сотни миллисекунд.

Пробовал (см. предыдущий пост).

Pzz>Тест твой, кстати, некорректен. Ты не учитываешь, что пакету требуется
Pzz>некоторое время, чтобы сбегать туда-сюда. И время это состоит не только
Pzz>из собственно передачи, но и включает время реакции сетевого стека и
Pzz>время, которое уходит на то, чтобы разбудить принимающую программу.

Pzz>За это время посылатель вполне может успеть отправить несколько пакетов,
Pzz>если не вставлять задержки.

Я знаю, что некорректен. Я не понимаю, что происходит. Ну шлю я пакеты с большой частотой, если ОС их не может отправить, то пусть сообщает об ошибке. Где в сокетах написано с какой частотой я могу слать пакеты? А потом, как тогда вообще нагрузить сеть в 1 Гб? У меня трафик никакой — сотые доли процента.

Здравствуйте, MaximE, Вы писали:


ME>Тут упоминалось, что проблема с потерей UDP пакетов свойственна виндозе. Попробуй линукс или фрю.


Никак не возможно. Может проблема и свойственна, но кто-то же должен знать из-за чего это все и при каких факторах возникает.

black_jesus wrote:
>
> Pzz>За это время посылатель вполне может успеть отправить несколько пакетов,
> Pzz>если не вставлять задержки.
>
> Я знаю, что некорректен. Я не понимаю, что происходит. Ну шлю я пакеты с
> большой частотой, если ОС их не может отправить, то пусть сообщает об
> ошибке. Где в сокетах написано с какой частотой я могу слать пакеты? А
> потом, как тогда вообще нагрузить сеть в 1 Гб? У меня трафик никакой —
> сотые доли процента.

Похоже, теряются они не на отправке, а на приеме. Никто при этом никому
ничего не сообщает.

Для справки, я умудряюсь передавать видео UDP'шными мултикастами. Это
600-700 полноразмерных пакетов в секунду. Пакеты передаются с Линуха на
Виндовс. Потерь по вине софта очень мало.

Да, на виндовсе я использую winsock2, но не использую overlapped I/O.

Все это работает довольно устойчиво, но мне пришлось подкрутить
SO_RCVBUF (помогло весьма заметно) и приоритет приемника (помогает
только при наличии какой-то активности в системе).

ME>Тут упоминалось, что проблема с потерей UDP пакетов свойственна виндозе. Попробуй линукс или фрю.
Скорее свойственна самому протоколу

Потеря пакетов — нормальное поведение UDP протокола, кроме потери они могут приходить в не правильном порядки, или вообще не приходить. Бороться с этим можно тольк она уровне своего собственного протокола.

On Wed, 16 Nov 2005 11:55:16 -0000, Tom <3627@users.rsdn.ru> wrote:

> Потеря пакетов — нормальное поведение UDP протокола, кроме потери они могут приходить в не правильном порядки, или вообще не приходить. Бороться с этим можно тольк она уровне своего собственного протокола.

Спасибо, мужик, просветил нас серых.

--
Maxim Yegorushkin

ME>Спасибо, мужик, просветил нас серых.
Незачто мужик, просветляйся

black_jesus wrote:
>
> aik>Я эти проблемы решаю по-лоховски — задираю приоритет принимающего
> потока на повыше (насколько — тут смотри сам, мне и
> THREAD_PRIORITY_ABOVE_NORMAL хватает), проблема решается на гораздо
> более тухлом железе.
>
> Пробовал, не помогает. Этого собственно и следовало ожидать. Так как
> пакеты, судя по всему, не уходят с моей машины, и им до приоритета
> потока чтения на другом конце как до лампочки.

Есть смысл взять Ethereal (http://www.ethereal.com/), и посмотреть,
действительно ли они не уходят, или все же не приходят.

Вообще, сниффер — чертовски полезная вещь при отладке сетевых протоколов.

Здравствуйте, Pzz, Вы писали:

Pzz>Для справки, я умудряюсь передавать видео UDP'шными мултикастами. Это
Pzz>600-700 полноразмерных пакетов в секунду. Пакеты передаются с Линуха на
Pzz>Виндовс. Потерь по вине софта очень мало.

В смысле пакеты по 65к? Т.е. болеее 37 МБ/с?

Pzz>Да, на виндовсе я использую winsock2, но не использую overlapped I/O.

Про overlapped I/O можно немного поподробнее, а то я недавно с сокетами ковыряюсь.

Pzz>Все это работает довольно устойчиво, но мне пришлось подкрутить
Pzz>SO_RCVBUF (помогло весьма заметно) и приоритет приемника (помогает
Pzz>только при наличии какой-то активности в системе).

У меня как раз активности ноль. Приложение в основном потоке крутит цикл опроса клавиатуры, а второй поток стоит в recvfrom()

black_jesus wrote:
>
> Pzz>Для справки, я умудряюсь передавать видео UDP'шными мултикастами. Это
> Pzz>600-700 полноразмерных пакетов в секунду. Пакеты передаются с Линуха на
> Pzz>Виндовс. Потерь по вине софта очень мало.
>
> В смысле пакеты по 65к? Т.е. болеее 37 МБ/с?

Ну нет, не фрагментированные конечно, т.е 1.5К плюс-минус копейки.
Скорость — около мегабайта в секунду (впрочем, в своих тестах я получал
и в 3 раза большую скорость, но с генератором траффика. Видеокодек
столько не выдает).

> Pzz>Да, на виндовсе я использую winsock2, но не использую overlapped I/O.
>
> Про overlapped I/O можно немного поподробнее, а то я недавно с сокетами
> ковыряюсь.

В Виндовсе можно работать с сокетами в двух разных стилях:
1) Как с BSD-совместимыми (socket, bind, connect, recv, send, select, ...)
2) Используя "родной" API (WSASocket, WSASend, WSARecv, ...)

Родной API, кроме всего прочего, позволяет делать т.наз. overlapped I/O.
Это когда функция возвращается сразу, а операция производится в
background'е. По завершении операции система может "просигналить" Event,
или даже позвать ваш callback (на контексте системного thread'а).

Родной API, видимо, эффективнее, но я пока не пробовал с ним играться. С
BSD-совместимим API загрузка процессора равна нескольким процентам, что,
признаться, раздражает. Особенно если учесть, что на соседней
linux-машине, которая все это посылает, загрузка процессора равна 0
целых 0 десятых процента, а процессор там заметно слабее (P3/1000 MHz vs
P4/2800 MHz).

Кроме того, независимо от того, используется ли BSD'шный или родной API,
можно использовать или winsock, или winsock2. Они отличаются мелкими
деталями поведения. Если предполагается работа с мултикастами, лучше
использовать winsock2. Для этого надо:
1) Писать #include <winsock2.h>, причем делать это до включения других
хидеров. Иначе подцепится winsock.h
2) линковаться ws2_32.lib, а не с wsock32.lib
3) Заказывать версию 2.0 при вызове WSAStartup()

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

rc = setsockopt(
sock, // Сокет, через который посылаем
IPPROTO_IP,
IP_MULTICAST_IF,
(void*) &addr, // IP-адрес сетевого интерфейса
sizeof( struct in_addr )
);

IP-адрес сетевого интерфейса указывается в виде ссылки на struct
in_addr, заполненной в сетевом порядке байтов. Если адрес указать
неправильно, форточки могут ничего не сказать, и просто проигнорировать
этот запрос.

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

> Pzz>Все это работает довольно устойчиво, но мне пришлось подкрутить
> Pzz>SO_RCVBUF (помогло весьма заметно) и приоритет приемника (помогает
> Pzz>только при наличии какой-то активности в системе).
>
> У меня как раз активности ноль. Приложение в основном потоке крутит цикл
> опроса клавиатуры, а второй поток стоит в recvfrom()

А у тебя цикл не зацикливается?

Какая у тебя загрузка процессора? Должна быть очень маленькая, все
потоки должны быть почти всегда заблокированны.

Есть смысл посмотреть Ethereal'ом, что там на самом деле происходит с
пакетами. Ethereal можно взать здесь: http://www.ethereal.com

Здравствуйте, Pzz, Вы писали:

Pzz>Кроме того, независимо от того, используется ли BSD'шный или родной API,
Pzz>можно использовать или winsock, или winsock2. Они отличаются мелкими
Pzz>деталями поведения. Если предполагается работа с мултикастами, лучше
Pzz>использовать winsock2. Для этого надо:
Pzz> 1) Писать #include <winsock2.h>, причем делать это до включения других
Pzz>хидеров. Иначе подцепится winsock.h
Pzz> 2) линковаться ws2_32.lib, а не с wsock32.lib
Pzz> 3) Заказывать версию 2.0 при вызове WSAStartup()

Я использую Winsock2 и как раз мультикаст, но с использованием BSD API

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

за интерфейс псасибо, как раз некоторые проблемы были


Pzz>Какая у тебя загрузка процессора? Должна быть очень маленькая, все
Pzz>потоки должны быть почти всегда заблокированны.

на загрузку не обращал внимания, надо будет посмотреть

Pzz>Есть смысл посмотреть Ethereal'ом, что там на самом деле происходит с
Pzz>пакетами. Ethereal можно взать здесь: http://www.ethereal.com

Установил, оказалось, что пакеты уходчт с машины и доходят до другого конца. При этом поведение программы на том конце такое: на первые несколько десятков посылок она отвечает, после чего перестает. Чего еще сообщить не знаю.

Еще еноднократно замечал такую вешь. На моем конце запускаю программу в режиме посылки данныхь и приема подтверждений, а на другом в режиме приема данных и посылки подтверждений. Программа на моем конце посылает 1000 посылок и заканчивается. На другом конце программа продолжает получать посылки по одной с интервалом примерно в 1 сек, т.е. когда отправитель уже прекратил их посылать и вообще закончил работу. Начал разбираться оказалось что на другой машине стоят включенными пара виртуальных сетевых адаптеров от виртуальной машины VMWare. Отключил, вроде прекратилось, но по-моему это не причина, так как наблюдал такое, когда там ВМ еще не было.

Здравствуйте, Pzz, Вы писали:

Pzz>В Виндовсе можно работать с сокетами в двух разных стилях:
Pzz> 1) Как с BSD-совместимыми (socket, bind, connect, recv, send, select, ...)
Pzz> 2) Используя "родной" API (WSASocket, WSASend, WSARecv, ...)

Pzz>Родной API, видимо, эффективнее, но я пока не пробовал с ним играться. С
Pzz>BSD-совместимим API загрузка процессора равна нескольким процентам, что,
Pzz>признаться, раздражает. Особенно если учесть, что на соседней
Pzz>linux-машине, которая все это посылает, загрузка процессора равна 0
Pzz>целых 0 десятых процента, а процессор там заметно слабее (P3/1000 MHz vs
Pzz>P4/2800 MHz).

Кривой код приемника. Если все делать правильно, то и в винде загрузка будет нулевая.
Вообще, "bsd" API работает через все те же сокет-провайдеры, что и win api. Т. е. разница — она в паре-тройке лишних call'ов в user-level, т. е. совсем смешное время. А вот если в потоке-приемнике и select, и WaitForXXXX использовать криво — тут да, накосячить можно.

aik wrote:
>
> Pzz>Родной API, видимо, эффективнее, но я пока не пробовал с ним играться. С
> Pzz>BSD-совместимим API загрузка процессора равна нескольким процентам, что,
> Pzz>признаться, раздражает. Особенно если учесть, что на соседней
> Pzz>linux-машине, которая все это посылает, загрузка процессора равна 0
> Pzz>целых 0 десятых процента, а процессор там заметно слабее (P3/1000 MHz vs
> Pzz>P4/2800 MHz).
>
> Кривой код приемника. Если все делать правильно, то и в винде загрузка
> будет нулевая.

Что в нем может быть кривого? Он ждет select'ом и принимает recvfrom'ом.
Сокет в select'е один, но select используется заодно для отработки
тайминга. Причем timeout в select'е в среднем большой (сотни
миллисекунд). Почти вся загрузка CPU приходится на kernel mode (если
верить GetProcessTimes()).

Код на линуксячей стороне очень похожий, только сокетов побольше, и
таймауты сильно поменьше (типично — 10ms). Логика вокруг select'а вообще
общая (т.е., один исходник используется на 2 системы).

При этом на линухе загрузка по нулям, а на форточках несколько
процентов, да еще иногда и подскакивает процентов до 10-15, без всякой
видимой причины...

Да, загрузка явно пропорциональна траффику.

У меня еще не дошли руки с этим плотненько поразбираться, но пока идей
никаких. Наверное, когда руки дойдут, напишу для начала тестовую
програмку, которая просто гонит поток по UDP, и поиграюсь. Например,
посмотрю, влияет ли select...

> Вообще, "bsd" API работает через все те же сокет-провайдеры, что и win
> api. Т. е. разница — она в паре-тройке лишних call'ов в user-level, т.
> е. совсем смешное время. А вот если в потоке-приемнике и select, и
> WaitForXXXX использовать криво — тут да, накосячить можно.

Это понятно, но кто его знает, как там эта эмуляция на самом деле
реализована

Здравствуйте, black_jesus, Вы писали:

_>Доброе время суток, уважаемые. Заранее извиняюсь,что повторяю уже ранее заданный вопрос, но я так и не нашел объяснения.
_>Пишу графическое приложение реального времени, работающее на нескольких машинах. Приложение-мастер (сервер) получает по TCP-сокетам данные с частотой примерно 100 Гц по 100 — 150 байт в посылке и должно синхронно ретранслировать данные еще на ряд клиентских машин. Ретрансляция реализована на UDP с помощью multicast. Все нормально работает и ничего не теряется (проверено), но иногда на сервер поступают дополнительные данные, несколько посылок тоже по 100 – 150 байт, которые тоже должны быть ретранслированы клиентам. Так вот в процессе ретрансляции этих посылок часть из них теряется. Заметив такое поведение решил написать отдельный тест и набрел на проблему, подобные которой неоднократно всплывали на этом форуме, но для себя я ответов так и не нашел. А проблема – потеря пакетов в зависимости от занятости приложения или нагрузки процессора.
_>Складывается ощущение, что физически пакеты передаются, но не обрабатываются операционной системой. Большая просьба к специалистам, подскажите в чем причина и, если кто знает, то как обойти проблему.

Я вот что заметил в твоем письме:"... кабели метровой длины ..."! Это есть не верно! Кабели должны быть длиной минимум
2 метра!!! Запомни это! Иначе возникают большие помехи (отраженные волны) в ходе информационного обмена. Удачи!

Здравствуйте, Tom, Вы писали:

Tom>Потеря пакетов — нормальное поведение UDP протокола, кроме потери они могут приходить в не правильном порядки, или вообще не приходить. Бороться с этим можно тольк она уровне своего собственного протокола.
Согласен(+), можно сколько угодно с пеной у рта доказывать, что при тестах пакеты не терялись, и что они практически никогда не теряются, но это не даст, тем не менее, совершенно никакой гарантии, что пакеты не будут теряться в дальнейшем или при изменении конфигурации системы/модели.

От себя добавлю, что это решается либо действительно написанием своего, хотя бы базового, протокола обмена, либо не решается вообще, как при обычном аудио-видео-вещании(т.е. потерялось, и хрен с ним, главное, контроль целостности кадров — пришел целый — показали, пришел битый — пропустили).

по поводу базовых протоколов можешь поискать например описание старых UDP-протоколов ICQ(до версии 5 включительно) — в инете эта инфа есть. у них там реализован несложный контроль очереди пакетов и механизм повторного запроса.

есть варианты и попроще. взять к примеру за основу TOC-протокол (используется как база в свежих версиях ICQ, AOL-messenger, Jabber кажется тоже, и т.п.). протокол открыт и прост, поэтому инфы навалом. в его случае, чтобы не заморачиваться с очередью всех подряд пакетов, можно просто создать пакетное окно и контролировать очередность пакетов в пределах окна, если нарушена, перезапросить все окно.

но меня смущает упоминание мультикаста в первом вопросе ветки... с этим сложнее. ведь каждому клиенту делать контроль передачи — потеряется скоростное преимущество мультикаста....

может все-таки решить это через TCP-сервер?

например, сервер принимает данные(откуда он их там берет), и укладывает в самораздувающийся буффер(любая реализация memory-stream, или доработанный FIFO-buffer), а подключенные клиенты фактически забирают данные уже из этого буффера. Суть — за счет длины буффера клиент может спокойно запросить передачу поврежденных пакетов повторно, без необходимости резервировать кучу памяти под контроль очереди для каждого клиента. как идейка?

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