Буфер приема необработанных сокетов

Question

В настоящее время мы тестируем приложение Telecom по IP. Мы открываем Raw Socket и получаем сообщения с удаленной стороны (msgrate @ 750 + msgs / секунда, примерно 180 байтов без учета IP).

В верхней части сокета Raw находится слой, называемый SCTP (точно так же, как TCP), который время от времени указывает, что ему не хватает некоторых пакетов. Теперь мы запускаем Wireshark на принимающем узле и видим этот пакет в Wireshark.

Мне кажется, что приемный буфер сокета мал, в результате чего IP (?) Отбрасывает сообщения. Тем не менее, IP Pegs (netstat -sv) показывают НЕТ отброшенных пакетов. Мы попытались установить очередь приема сокетов равной 40000, но безуспешно.

Буду признателен за любые указания относительно того, какую опцию, если таковая имеется, уровня IP следует настраивать или есть какая-либо конкретная опция сокета, которую нам нужно установить.

Answer 1

Спасибо за ваш вклад. Однако мы смогли «решить» эту проблему. Ранее я описал, как мы читаем сообщения. После того, как select возвращает, мы запускаем цикл (на количество прочитанных необработанных сообщений, которое в нашем случае было> 1). 1) мы вызываем ioctl (FIONREAD), чтобы найти количество байтов для чтения; 2) прочитать столько байтов, вызвав recvfrom 3) отправить байты пользователю 4) снова войдите в цикл и вызовите ioctl (FIONREAD), а затем повторите шаги

Однако в пункте 4 ioctl (FIONREAD) использует для возврата 0. Наш код прошел защитную проверку. Ожидалось, что 0 байтов от ioctl (FIONREAD) означают, что отправитель отправил заголовок IP с 0 полезными данными. Поэтому он используется для вызова recvfrom (байты для чтения = 0), чтобы очистить заголовок IP, чтобы выбор не установился снова.

В момент времени t0 ioctl (FIONREAD) возвращает 0 как число байтов для чтения. В момент времени t1 вызывается recvfrom (байты до чтения = 0). Иногда, между t0 и t1, фактические данные используются для постановки в очередь в очереди приема сокета и используются для отбрасывания при вызове recvFrom (bytes = 0).

Установка, число rawMsgsToRead = 1 "решило" эту проблему. Тем не менее, я думаю, это повлияет на нашу производительность. Это любой вызов ioctl, который может различать октеты в очереди как 0 и заголовок IP с полезной нагрузкой 0

Answer 2

У меня есть несколько вопросов и несколько вещей для размышления. 1) Какую реализацию SCTP вы используете и на какой ОС. Некоторые реализации SCTP более надежны, чем другие. 2) SCTP отрицательно подтверждает отброшенные пакеты? Ищите брешь в акше. 3) И где вы видите пропущенные пакеты в Wireshark, вы уверены, что это не повторные передачи? 4) Где в системе находится мониторинг Wireshark? Если он не подключен к вашему приложению, возможно, он видит сообщения, которых нет в вашем приложении. 5) Что именно указывает SCTP?

Если вы полагаете, что буфер Rx IP-сокета переполнен, то вы можете рассмотреть вопрос об уменьшении размера окна RTP SCTP; это часто настраивается в стеках sctp. Окно Rx ограничивает объем данных, которые могут находиться в состоянии ожидания, ожидая подтверждения, и, следовательно, ограничивает объем данных, которые могут находиться в буфере IP. Вы также можете попытаться повысить приоритет своей задачи SCTP, чтобы она быстрее считывала сообщения из IP-буферов (это может быть самая простая попытка, и, на мой взгляд, хорошая вещь).

Привет