udp Определить пропажу пакета
Добрый день. Требуется передать сообщения размером до 10 мб между ПК. Данные разделяются на блоки по 1кб. Не требуется установка соединения, отправка идёт широковещательно.
На приемной стороне нужно понять что пакеты потерялись или перемешались, не предпринимая мер к повторной отправке (просто отбросить). Попробовал табличный crc32 однако для сообщений
10мб время расчета составляет около 400 мс что для задачи недопустимо долго.
По идее датаграмы udp уже имеют контрольную сумму и нужно лишь определить факт потери или перемешивания. Не хочется добавлять в килобайтные блоки дополнительный заголовок. Может кто сталкивался?
после нарезки добавить номер (циклический и достаточно большой чтобы не часто повторятся) для каждого пакета. и написать алгоритм учета последовательности номеров пакетов в приемнике.
Посмотри протоколы типа fast и sbe, и то как их использовали на том же moex, вдохновись так сказать. В кратце — нужно ввести сквозной номер пакета.
казнить нельзя помиловать
при такой постановке задачи, это не решается вообще
он же написал, без доб заголовков
Как ты собираешься проверить целостность данных без избыточности. Можно каждый пакет нумеровать, когда избыточность — это сумма всех счетчков (в заголовке). Можно контрольную сумму считать и передать в конце дополнительно спец пакет с этой контрольной суммой и узнать что сообщение из нескольких пакетов испорчено. Можно коды Хеминга или Рида-Соломона прикрутить и восстанавливать(!) битые пакеты.
Я читал что дополнительный заголовок с пользовательскими данными можно сделать при вызове системных функций, чтобы эти данные не выбирать из блоков сообщения, а сама система это сделает.
Я для себя просто не представляю быстрой работу алгоритма когда данные из килобайтных блоков надо выковыривать и склеивать, а не читать огромным сплошным куском (как сделано сейчас), в котором пришедшие блоки лежат последовательно в адрессном пространстве.
На приемной стороне нужно понять что пакеты потерялись или перемешались, не предпринимая мер к повторной отправке (просто отбросить).
Вообще это один-в-один требования к кодированию голоса в IP телефонии, когда перемешивать нельзя для корректного декодирования, а то что потеряно — уже не нужно. Так что гугли про RUDP. Но без хидеров никак.
Я читал что дополнительный заголовок с пользовательскими данными можно сделать при вызове системных функций, чтобы эти данные не выбирать из блоков сообщения, а сама система это сделает.
Ты уж определись, нужен тебе дополнительный заголовок или нет. А кто этот заголовок сделает — это уже дело десятое.
В общем, тебе нельзя помочь. Успехов
Вообще это один-в-один требования к кодированию голоса в IP телефонии, когда перемешивать нельзя для корректного декодирования, а то что потеряно — уже не нужно.
Ну всё же не совсем. Обычно есть буфер, там могут копиться перемешанные и восстанавливаться и ожидаться задержанные.
А зачем проверка корректности пакета в голосе?
10мб время расчета составляет около 400 мс
Как и на чём считаешь?
Без доп заголовков — пусть себе tcp использует или голый ip. Сэкономить 4ре байта это такое себе по сравнению со сменой стека.
Я по-прежнему щетаю, что ТС либо запускает свой код на тостере, либо очень медленно щетает.
На коленке накорябанный на жабке бенчмарк, за который меня будут больно бить, показывает
3 мс на 10 мегабайтах в неразрывном буфере:
не корректность а порядок пакетов
не надо перекручивать смысл сказанного
а для понимания, возьмите любой вав файл или пцм
нарежте на одинаковые куски(в ваве ясно дело данные а не с хидером)
анон, как и обычно, флудит тупаком с кучей пустых строк.
pepehands.bmp
Нумерация пакетов же.
чья бы корова мычала лол [quote] Nick: izzholtik ID: 176586
Дата регистрации: 24.03.20 20:18:24 Последнее посещение: 30.07.20 11:06:22 Статус: новый пользователь В игноре:
Oberstserj — пустослов LGH — тупак, грубиян SM5T001 — тор головного мозга Забавные люди:
Black_Shadow — верит всему хорошему про AMD и не верит всему плохому t184256 — у сестры обои на телефоне похожи на его аватарку [/quote]
Crc32 в табличной реализации.
crc32 довольно медленная функция, можно попробовать xxhash32 или xxhash64.
Ну, OpenJDK берёт реализацию crc32 из zlib, а там я вижу вот это вот. Да и какая разница, табличная реализация или «в лоб», если скорость достаточная?
Спасибо. Обязательно попробую
А «система» за тебя это делает конечно же на квантовом сопроцессоре, поэтому все так быстро. Просто передает квантовому стирателю указатель на заголовок пакета, и вот в памяти уже как бы и не заголовок пришел, а сам пакет, какой еще заголовок, не было ничего.
работу алгоритма когда данные из килобайтных блоков надо выковыривать и склеивать
А чо там принципиально сложного? Зарезервировал массив из 10240 1024-байтных блоков. По приходу пакета прочитал номер пакета из первых 2 байтов, используешь его как смещение в массиве и копируешь оставшиеся 1024 байт по этому смещению. В итоге получаешь плоский упорядоченный регион в памяти с данными (это если потерь пакетов не было). Можно пожертвовать плоскостью памяти, если не хочется данные копировать, и сделать битовый массив, взводить в нем бит если пакет пришел, потом идти по этому массиву и по простой формуле вычислять смещение блока
Источник
Русские Блоги
Анализ проблем пакета UDP в системе Linux
Эта ссылка на статью
Недавно я встретил серверную заявку UDP потери пакетов. Я провел много информации во время процесса расследования. Я в основном использую TCPDUMP для захвата во всех аспектах проблемы. Проанализировать в этой ссылке. Вопрос, предназначенный для устранения неполадок проблем, нажимает Болезнь, и, наконец, проблема может быть решена. Однако эта ситуация заключается в том, что проблема самой службы, если это экологическая проблема, операционная система и даже проблемы с аппаратными средствами, она может не быть в состоянии решить проблемы с самого обслуживания, но эта статья будет иметь другой подход, от Внешний экологический анализ причины, после прочтения, это очень полезно, некоторые главы были изменены к исходному тексту и поделитесь его для большего количества людей.
Прежде чем начать, давайте будем использовать диаграмму, чтобы объяснить процесс получения сетевых пакетов в системе Linux.
Во-первых, веб-пакет отправляется в NIC через физический сетевой кабель.
Драйвер сети считывает пакеты в сети для кольца буфера, этот процесс использует DMA (прямой доступ к памяти), не участие ЦП
Ядро читает сообщение из кольцевого буфера для выполнения логики слоев IP и TCP / UDP и, наконец, поместите сообщение в буфер приложения.
Приложение обрабатывается из буфера сокета
Во время приема пакетов UDP любая из процессов может быть отброшена или пассивно, поэтому потеря пакета может происходить в NIC и DRIVE, или может происходить в системах и приложениях.
Причина, по которой нет анализа для отправки процесса данных, один состоит в том, что процесс передачи аналогичен, но направление обращается к обращению; вероятность того, что потеря пакета передачи является небольшим, только когда скорость нанесения, отправленная приложением, является больше Чем частота обработки ядра и сетевой карты произойдет.
Эта статья предполагает, что только одно имя eth0 Интерфейс, если есть несколько имен интерфейса или интерфейса, а не ETH0, следуйте фактической ситуации.
Примечание: RX (Прием) означает получение пакета, TX (Передача) означает отправку сообщения.
Убедитесь, что есть потеря пакета UDP
Чтобы увидеть, имеет ли NIC пакет, вы можете использовать ethtool -S eth0 Вид, ищите на выходе bad Или же drop Есть ли соответствующее поле данных, в обычном случае числа, соответствующие этим полям, должны быть 0. Если вы видите соответствующий номер, вы объясните, что у NIC есть пакет.
Другая команда для просмотра данных потери пакета сети ifconfig Это будет иметь его в своем выходе RX (Получить приемный пакет) и TX (Передача отправка пакета) Статистика:
Кроме того, система Linux также обеспечивает информацию о потерях пакетов для каждого сетевого протокола, который можно использовать. netstat -s Команда представления, плюс —udp Вы можете посмотреть только на сообщения сообщения, связанные с UDP:
Для вышеуказанного выхода обратите внимание на следующую информацию, чтобы просмотреть случай, когда пакет UDP:
packet receive errors Не пусто, и в течение длительного времени система имеет удр пакетов UDP
packets to unknown port received Целевой порт, указывающий, что сообщение UDP, полученное системой, не используется в прослушивании. Обычно это вызвано услугой без запуска и не вызывает серьезных проблем.
receive buffer errors Указывает, что количество потери пакетов вызвано, потому что приема UDP слишком мала.
NOTEНе количество потери пакета не равно нулю, для UDP, если существует небольшое количество потери пакета, вероятно, ожидаемое поведение, такое как скорость потерь пакетов (количество пакетов для пакетов / приема), составляет один миллион еще меньше.
Ник или привод потеря пакета
Я сказал раньше, если ethtool -S eth0 Посередине rx_***_errors Тогда это, вероятно, проблема с сетевой картой, вызывая терять пакет, вам необходимо связаться с сервером или поставщиком сетевого карта для обработки.
netstat -i Он также доступен для приемных пакетов каждого NIC и корпус потери пакетов, а ошибка или падение должны быть 0 на выходе.
Если аппаратное обеспечение или драйвер не проблема, общая сетевая карта теряется, потому что набор буфер слишком мал, вы можете использовать ethtool Команда для просмотра и настройки кольцевого буфера для сети.
ethtool -g Вы можете просматривать кольцевой буфер сетевой карты, такой как пример ниже.
Предварительный набор представляет наибольшее значение буфера кольца NIC, вы можете использовать ethtool -G eth0 rx 8192 Установите его значение.
Linux System потери пакета
Существует много причин для потери пакета Linux System, общие: пакеты UDP, брандмауэр, размер буфера UDP, системные нагрузки высоки, и эти причины потери пакета анализируются.
Ошибка пакета UDP
Если пакет UDP модифицирован во время передачи, ошибка контрольной суммы или ошибка длины, Linux проверяет это, когда сообщение UDP получено, и сообщение будет отброшено после того, как изобретение будет отказаться от сообщения.
Если вы хотите контрольную сумму UDP пакета, вы должны отправить его в свое приложение вовремя, вы можете проверить проверку контрольной суммы UDP в параметре сокетов.
Брандмауэр
Если система брандмауэра потери пакета, поведение производительности, как правило, все, как правило, все пакеты UDP, и, безусловно, не исключают возможности только брандмауэра только падать.
Если вы столкнулись с множеством соотношения убытков пакетов, сначала проверьте правила брандмауэра и убедитесь, что брандмауэр не активно падает пакеты UDP.
Размер буфера UDP
После того, как система Linux принимает сообщение, система Linux сохранит пакет в область кэша. Поскольку размер кэша ограничен, если пакет UDP слишком велик (превышает размер кэша или размер MTU), скорость получения сообщения слишком быстро, что может привести к тому, что Linux пакет находится непосредственно с помощью кэша.
На уровне системы Linux устанавливает максимальное значение того, что буфер приема может настроить, и можно просматривать в следующем файле, который, как правило, Linux устанавливает начальное значение на основе размера памяти при запуске.
/ proc / sys / net / core / rmem_max: разрешено принять максимум буфера
/ proc / sys / net / core / rmem_default: Получить значение буфера, используемое по умолчанию
/ proc / sys / net / core / wmem_max: максимальное значение разрешено быть установленным
/ proc / sys / net / core / wmem_dafault: максимальное значение, используемое по умолчанию
Однако эти начальные значения не должны устранять пакеты UDP большого потока. Если приложение получает и отправляет UDP-сообщения, необходимо сказать это значение. можешь использовать sysctl Команда позвольте вступить в силу немедленно:
Также может быть изменено /etc/sysctl.conf Соответствующие параметры позволяют параметрам вступать в силу на следующем запуске.
Если пакет слишком велик, отправитель может разделить данные, чтобы гарантировать, что размер каждого сообщения находится в MTU.
Другой параметр, который можно настроить, это netdev_max_backlog Он указывает на то, что ядро Linux читает номер пакета после прочтения сообщения от драйвера сети, по умолчанию составляет 1000, что может быть защищено, например, установлено на 2000:
Системная нагрузка слишком высока
System CPU, память, нагрузка на io наполнено, чтобы вызвать потеря сетевой пакеты, такой как CPU, если нагрузка слишком высока, система не успевает сделать сообщение, копировать память и т. Д. Потеря пакета; Память нагрузка слишком высока, приложение слишком медленно, и сообщение не может быть обрабатывается во времени; если нагрузка на io слишком высока, процессор используется для ответа на IO ждать, нет времени для обработки UDP пакеты в кеше.
Сама система Linux является взаимосвязанной системой, и любой компонент может повлиять на нормальную работу других компонентов. Для системы нагрузки слишком высоки, или если есть проблема с приложением, или система недостаточна. Для прежних потребностей, отладки и ремонта; для последнего, также можно найти и расширяться во времени.
Применяемый
Размер буфера UDP системы упоминается выше, параметр регулировки SYSCTL — это просто максимальная допустимая система, каждое приложение должно устанавливать значение размера буфера сокета при создании сокета.
Система Linux поставит принятые пакеты в буфер сокета, а приложение постоянно читает пакеты из буфера. Таким образом, есть два и приложения, связанные с приложениями, которые влияют на размер размера буфера разъема и приложение прочитал пакет.
В течение первого вопроса вы можете установить размер буфера приема розетки, когда приложение инициализирует сокет, например, следующий код устанавливает буфер сокета до 20 МБ:
Если это не программа, которую вы пишете и обслуживаете, измените код приложения не хороши или даже менее вероятно. Многие приложения предоставляют параметры конфигурации для настройки этого значения, обратитесь к соответствующему официальному документу; если нет доступных параметров конфигурации, вы можете дать только разработчику программы, чтобы указать проблему.
Очевидно, что увеличение буферов приема приложений уменьшит возможность потери пакета, но в то же время она приведет к использованию приложения большего количества памяти, поэтому его необходимо использовать с осторожностью.
Другим фактором является применение скорости пакетов в буфере. Для приложений пакеты обработки должны принимать асинхронный путь.
Где пакет?
Если вы хотите узнать больше о том, какая функция брошена, вы можете использовать ее. dropwatch Инструменты, оно слушает информацию о потерях системной пакеты и распечатает адрес функции пакета из пакета:
Благодаря этой информации найдите соответствующий код ядра, вы можете знать, какой этап ядра отбрасывается, и причина потери общего пакета. Я более склонен к различным захватам машины в процессе исследования этой проблемы, этот метод более подходит для отслеживания вашего собственного бизнеса, что приведет к потере пакета, как показано ниже:
Кроме того, вы также можете использовать инструмент Linux Perf для прослушивания kfree_skb (Когда сетевое сообщение отбрасывается, функция будет называться) инцидент:
Об использовании и интерпретации Perf Commands, есть много статей в Интернете.
Сам UDP является неисправным протоколом, который применим к сценарию пакетов и не влияет на состояние программы, например видео, аудио, игру, мониторинг и т. Д. Приложения, которые являются относительно высокими в надежности пакетов, не используют UDP, и рекомендуется использовать TCP напрямую. Конечно, вы также можете попробовать еще раз в слое приложений, чтобы обеспечить надежность
Если сервер обнаружен, сначала монитор нагрузки системы слишком высока, затем найдите нагрузку, чтобы уменьшить нагрузку и проиграть проблему исчезнула.
Если система нагрузки слишком высока, потеря пакета UDP не является эффективным решением. Если исключение приложения вызывает процессор, память, IO, своевременное расположение исключений и исправлений и исправлений; если недостаточно, мониторинг должен иметь возможность обнаружить и быстро расширяться во времени
Для системы большого количества приемных или отправки пакетов UDP вы можете уменьшить вероятность потери пакетов, регулируя размер буфера сокета системы и программы.
Когда приложение имеет дело с пакетами UDP, не имеют слишком много логики обработки между приемными сообщениями дважды.
рекомендую:
Обратите внимание или «смотреть», искренняя благодарность!
Источник
