Имеется клиент с протоколом UDP. Изменить это нельзя. От него приходят пакеты с определённой информацией. Клиент это девайс, к компьютеру с Windows подключен напрямую патч-кордом. В целом всё работает, но иногда бывают непонятные проблемы. Пакеты приходят маленькие. В ОС с ними работает обычная программа из юзерспейса. К сожалению в протоколе нет номеров пакетов или ещё какой-либо информации.

Правильно ли я понимаю, что размер UDP буфера в Windows 32 KB (для каждого сокета)? От клиента данные приходят со скоростью примерно 1.6 KB/s (20 пакетов в секунду). То бишь буфера хватает на 20 секунд. Программа работает постоянно, задержек больше, чем на сотые доли секунды не бывает, значит с размером буфера проблем быть не может.

Можно ли быть уверенными, что сетевые драйверы в Windows гарантируют упорядоченность пакетов после того, как они их приняли, если в буфере место не кончилось?

Можно ли быть уверенными, что если патч-корд хороший, то потерь и переупорядочиваний пакетов на таких скоростях быть не может?

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

vsb>Имеется клиент с протоколом UDP. Изменить это нельзя. От него приходят пакеты с определённой информацией. Клиент это девайс, к компьютеру с Windows подключен напрямую патч-кордом. В целом всё работает, но иногда бывают непонятные проблемы. Пакеты приходят маленькие. В ОС с ними работает обычная программа из юзерспейса. К сожалению в протоколе нет номеров пакетов или ещё какой-либо информации.

В таком прямом подключении — я бы оценил вероятность out-of-order как крайне низкую, доли процента. Скорее, тут может оказаться баг на стороне девайса-отправителя. В качестве траблшутинга можно попробовать поставить в разрыв ещё один комп с двумя сетевухами, например, который будет тупо форвардить через IP tables пакеты с одного интерфейса на другой и попутно делать pcap-дампы куда-то. Когда обнаруживаем проблему, можно поднять дампы и попытаться анализировать в WireShark или где ещё.

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

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

vsb>>Имеется клиент с протоколом UDP. Изменить это нельзя. От него приходят пакеты с определённой информацией. Клиент это девайс, к компьютеру с Windows подключен напрямую патч-кордом. В целом всё работает, но иногда бывают непонятные проблемы. Пакеты приходят маленькие. В ОС с ними работает обычная программа из юзерспейса. К сожалению в протоколе нет номеров пакетов или ещё какой-либо информации.

давно было обсуждение подобно проблемы в аудио процессинге — с участием форумчанина Музыченко — который сам пишет драйвера — обычно в азио драйверах можно ставит разные частоты поступления пакетов через размер буфера сэмплов
на звуковой карте, гуглить можно по ASIO for ALL настройки размера буфера-
начиная с некоторой частоты поступления буферов т.е. при маленьком размере буера начинают сбои в звуке.
то есть ваш случай похож и сбои могут быть.

Однако внутри своих драйверов, как говорил Музыченко, частоты поступления могут быть до сотен герц без сбоев.

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

vsb>Имеется клиент с протоколом UDP. Изменить это нельзя. От него приходят пакеты с определённой информацией. Клиент это девайс, к компьютеру с Windows подключен напрямую патч-кордом. В целом всё работает, но иногда бывают непонятные проблемы. Пакеты приходят маленькие. В ОС с ними работает обычная программа из юзерспейса. К сожалению в протоколе нет номеров пакетов или ещё какой-либо информации.

UDP не обрезает пакетов сам. Если пакеты перестают помещаться в буфер сокета, то пакет будет отброшен, а не обрезан.

Единственное место, где пакет может быть обрезан, это когда вызову recv() передают слишком маленький буфер для результата.

vsb>Правильно ли я понимаю, что размер UDP буфера в Windows 32 KB (для каждого сокета)? От клиента данные приходят со скоростью примерно 1.6 KB/s (20 пакетов в секунду). То бишь буфера хватает на 20 секунд. Программа работает постоянно, задержек больше, чем на сотые доли секунды не бывает, значит с размером буфера проблем быть не может.

Он управляется параметром SO_RCVBUF. Чего там по умолчанию, я уже забыл, но имеет смысл явно ставить, во избежании сюрпризов.

https://learn.microsoft.com/ru-ru/windows-hardware/drivers/network/so-rcvbuf (аж даже по-русски, до чего дошел прогресс...)

vsb>Можно ли быть уверенными, что сетевые драйверы в Windows гарантируют упорядоченность пакетов после того, как они их приняли, если в буфере место не кончилось?

vsb>Можно ли быть уверенными, что если патч-корд хороший, то потерь и переупорядочиваний пакетов на таких скоростях быть не может?

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

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

vsb>>Имеется клиент с протоколом UDP. Изменить это нельзя. От него приходят пакеты с определённой информацией. Клиент это девайс, к компьютеру с Windows подключен напрямую патч-кордом. В целом всё работает, но иногда бывают непонятные проблемы. Пакеты приходят маленькие. В ОС с ними работает обычная программа из юзерспейса. К сожалению в протоколе нет номеров пакетов или ещё какой-либо информации.

Pzz>UDP не обрезает пакетов сам.

Сорри, непонятно написал. Проблема не в том, что пакеты обрезаются. Пакеты маленькие это просто такие пакеты. Типа с MTU проблем не может быть и тд. В чем проблема я не понимаю, по сути данные приходят странные. Я предполагаю, что это глючит девайс. Но теоретически такое могло бы быть, если бы некоторые пакеты приходили не в том порядке. Понять, в каком порядке они должны приходить, нельзя, нет в пакетах такой информации, там только сырые данные.

Грубо говоря есть термометр, который по UDP шлет результаты измерений непрерывным потоком. И определенные места не соответствуют реальности.

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

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

vsb>Грубо говоря есть термометр, который по UDP шлет результаты измерений непрерывным потоком. И определенные места не соответствуют реальности.

А что значит, "не соответствует реальности"?

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

vsb>>Грубо говоря есть термометр, который по UDP шлет результаты измерений непрерывным потоком. И определенные места не соответствуют реальности.

Pzz>А что значит, "не соответствует реальности"?

Ну к примеру вместо одного пика два. В общем не должно так быть. Входные данные у него фиксированные, выходные данные должны иметь определенную форму и они в целом её имеют, но с некоторыми искажениями, которые в теории можно было бы объяснить переставленными пакетами, хотя я не совсем в этом уверен, но это хоть какое-то объяснение кроме варианта со сломанным девайсом (которое тоже спорно, т.к. их несколько таких).

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

vsb>Ну к примеру вместо одного пика два. В общем не должно так быть. Входные данные у него фиксированные, выходные данные должны иметь определенную форму и они в целом её имеют, но с некоторыми искажениями, которые в теории можно было бы объяснить переставленными пакетами, хотя я не совсем в этом уверен, но это хоть какое-то объяснение кроме варианта со сломанным девайсом (которое тоже спорно, т.к. их несколько таких).

Они (пакеты) редко переставляются на большое расстояние.

А насколько у тебя большой поток пакетов, в среднем и в пике?

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

vsb>>Ну к примеру вместо одного пика два. В общем не должно так быть. Входные данные у него фиксированные, выходные данные должны иметь определенную форму и они в целом её имеют, но с некоторыми искажениями, которые в теории можно было бы объяснить переставленными пакетами, хотя я не совсем в этом уверен, но это хоть какое-то объяснение кроме варианта со сломанным девайсом (которое тоже спорно, т.к. их несколько таких).

Pzz>Они (пакеты) редко переставляются на большое расстояние.

Pzz>А насколько у тебя большой поток пакетов, в среднем и в пике?

20 пакетов в секунду по 80 байтов в каждом. Скорость должна быть стабильной (но не всегда стабильна, но я пока эту проблему не воспроизвёл, возможно там какая-то кривая сеть была).

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

vsb>20 пакетов в секунду по 80 байтов в каждом. Скорость должна быть стабильной (но не всегда стабильна, но я пока эту проблему не воспроизвёл, возможно там какая-то кривая сеть была).

Чтобы пакеты переставились, они должны одновременно где-то храниться. Вошли туда в порядке 1-2-3, повалялись там, вышли в порядке 3-1-2

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

Ищи проблему или в своей программе, или в железке.

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

При исправной сетевой карте и кабеле подключенном напрямую, потери пакетов крайне редкое явление, а переупорядочивание — почти невероятное.
Буфер на входе можно поставить размером пару мегабайт — хотя обычно не надо.
Полагаться на стабильные задержки чтения нельзя — ОС живет своей жизнью. Более-менее стабильный интервал можно держать на SetWaitableTimer в отельном потоке, хотя все равно уползет.
Читать и обрабатывать придеться сразу при поступлении — проще всего запустить отдельный поток и синхронно ждать в нем данных.
Менее варварские альтернативы куда сложнее — вам судя по вопросам оно не надо, иначе придется узнать много того, чего вам бы знать не хотелось.
Самое простое просто тупо писать все что поступает с сокета в циклический буфер и запоминать timepoint и offset самого свежего постоупления, а обрабатывать и показывать прямо в GUI потоке. Про попытку выдержать точные интервалы — забыть. Достаточно что данные идут последовательно а равномерность их показа на экран глазу не заметна.

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

vsb>Можно ли быть уверенными, что сетевые драйверы в Windows гарантируют упорядоченность пакетов после того, как они их приняли, если в буфере место не кончилось?
vsb>Можно ли быть уверенными, что если патч-корд хороший, то потерь и переупорядочиваний пакетов на таких скоростях быть не может?

Нельзя ни в чем быть уверенным. ПАКЕТНАЯ передача информации в отличии от ПОТОКОВОЙ, тем и отличается, что пакеты гарантируют
только целостность содержимого, а не взаимный порядок. Драйвер на стыке с картой может иметь несколько буферов, куда карта будет
складывать принятые пакеты, или из которых будет отправлять. И записываться процессором и читаться картой, или наоборот, записываться
картой и читаться процессором буфера могут в разном порядке. И хуже того, такую проблему при траффике весьма далёком от полной
загрузки (100/1000 МБит/сек) можно и не замечать. И потом проблемы может добавить даже коммутатор (свитч).

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

vsb>Ну к примеру вместо одного пика два. В общем не должно так быть. Входные данные у него фиксированные, выходные данные должны иметь определенную форму и они в целом её имеют, но с некоторыми искажениями, которые в теории можно было бы объяснить переставленными пакетами, хотя я не совсем в этом уверен, но это хоть какое-то объяснение кроме варианта со сломанным девайсом (которое тоже спорно, т.к. их несколько таких).

Я бы сдампил весь трафик и проанализировал пакеты от девайса пост-фактум. Можно нарисовать график в твоём софте и в анализаторе трафика и сопоставить их.

Если сбоит именно железка, можно вырезать аномалии, если это приемлемо.

Здравствуйте, vsb, Вы писали:
vsb>>Можно ли быть уверенными, что сетевые драйверы в Windows

предположим Градусник это юзер в винде
предположим Приемник это тоже юзер в внде

тогда сбои возможны и на передаче из-за того что винда для юзера не реал-тайм ос
и
тогда сбои возможны и на приеме из-за того что винда для юзера не реал-тайм ос

и возможны сбои в сети
---
нужно протестировать приемник
для этого нужен 100% гарантированный четкий стабильный источник тестовых пакетов и это не градусник конечно

нужно протестировать градусник — для этого нужен 100% точно работающий софт приема пакетов и это не ваш софт приемника конечно

если первые два пункта 100% ок — ну тогда все же что-то с сетью

vsb>Можно ли быть уверенными, что сетевые драйверы в Windows гарантируют упорядоченность пакетов после того, как они их приняли, если в буфере место не кончилось?
Конечно же нет, драйверы в винде имеют асинхронную природу обработки запросов на прерывание — пришедший пакет генерирует IRP на обработку, первичный обработчик прерывания может вызваться на определенном процессоре, и пока он не завершится, другой пакет может интерраптнуть совсем другой процессор, и вот они будут примерно паралелльно исполняться, и каждый из них в какой то момент обычно инициирует DPC которая добавиться в очередь соответствующего процессора. DPC начнет исполнятся в тот момент когда все остальные DPC стоявшие в этой очереди завершатся. Далее вовсе не обязательно что эта DPC доделает все что надо и данные наконецто придут в юзермод. Она может породить APC а та например может вообще постучаться в юзермодный процесс файрволла чтобы тот сказал — нормуль ли пакет. И вот после всего этого та APC вызовет IoCompleteRequest, завершив таким образом обработку IRP.
Тут уже как минимум 3 места где видны гонки между двумя последовательными пакетами:
1) Процессоры могут исполнять обработчики прерывания не одинаково быстро — кеши то у них свои, так что все задержки обращения к памяти могут отработать по разному. Кроме того нынче пришла мода на несимметричный мультипроцессинг, когда соседние процессоры вообще на разных частотах работают.
2) Очерелдь DPC у каждого из процессоров на момент помещения в нее DPC на обработку пакета может иметь различное количество других запросов от других драйверов которые еще и сами по себе могут исполняться очент различное время.
3) Если в дело примется файрволл то он может вообще жевать каждый конкретный IRP сколько ему угодно времени. Может ему в каком нить пакете первые два байта затриггерят какую нить усиленную проверку сигнатур и он будет полсекунды ковыряться в своей базе...

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

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

vsb>Имеется клиент с протоколом UDP. Изменить это нельзя. От него приходят пакеты с определённой информацией. Клиент это девайс, к компьютеру с Windows подключен напрямую патч-кордом. В целом всё работает, но иногда бывают непонятные проблемы. Пакеты приходят маленькие. В ОС с ними работает обычная программа из юзерспейса.

Отлаживаем программу из юзерспейса, полагаю?

vsb> К сожалению в протоколе нет номеров пакетов или ещё какой-либо информации.

Раз нет — то предлагаю завести.

1. Вместо девайса пачкордом цепляется другой компьютер, которых шлёт похожие UDP-пакеты с нужной частотой, но в которых будет информация о порядке. Тогда можно будет в программе юзерспейса определить, в правильном ли порядке они попадают из драйвера. Но это в самом деле паранойя, я бы в такое не оч верил
2. Наоборот, вместо программы по приёму по UDP поставить дампер, который тупо будет в файл писать. Записать пару дней данных, ну или типовые примеры, проанализировать оные, тут зависит от предметной области. Их же потом можно будет и программе скармливать.

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

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

D>Отлаживаем программу из юзерспейса, полагаю?

Нет, это видно по результатам работы.

D>Раз нет — то предлагаю завести.

D>1. Вместо девайса пачкордом цепляется другой компьютер, которых шлёт похожие UDP-пакеты с нужной частотой, но в которых будет информация о порядке. Тогда можно будет в программе юзерспейса определить, в правильном ли порядке они попадают из драйвера. Но это в самом деле паранойя, я бы в такое не оч верил
D>2. Наоборот, вместо программы по приёму по UDP поставить дампер, который тупо будет в файл писать. Записать пару дней данных, ну или типовые примеры, проанализировать оные, тут зависит от предметной области. Их же потом можно будет и программе скармливать.

Проблема в том, что программа работает на диком зоопарке компьютеров, от vista до 11, с самым разным железом. И к этому железу особо доступа нет, чтобы взять и там на каждом компьютере разводить тестирование. У большинства всё работает нормально.

vsb>Выходит, что единственный надёжный способ тут что-то сделать, это сделать свой девайс на ардуино или чем-то подобном с ethernet-портом и максимально низкоуровневым API, чтобы девайс был достаточно примитивным и ни о каком упорядочивании уже речь не шла и передать его уже оттуда на компьютер?
Можно еще написать свой драйвер для какой нить определенной сетевухи, которая (предварительно выяснив это стресс тестами) не делает переупорядочивания внутри себя. Этот драйвер в свою очередь должен выплевывать данные "своей" аппликухе по своему личному каналу, который бы не допускал переупорядочивания — то есть обрабатывать все прерывания одним процессором и гнать в апликуху по своему каналу, а не по tcp/ip стеку системы.
Впрочем, на ардуино может оказаться легче)

vsb>Выходит, что единственный надёжный способ тут что-то сделать, это сделать свой девайс на ардуино или чем-то подобном с ethernet-портом и максимально низкоуровневым API, чтобы девайс был достаточно примитивным и ни о каком упорядочивании уже речь не шла и передать его уже оттуда на компьютер?
Вообще не проще ли при такой постановке вопроса обновить прошивку железяки чтоб слала порядковый номер?
Если страшно сломать обратную совместимость между новым девайсом и старым софтом (или наоборот), то можно заюзать к примеру UDP source port в качестве такого поля-счетчика.