2013-03-15 3 views
0

Я использую блокировку гнезда BOOST ASIO на платформе Linux. В некоторых операциях read() я вижу массивную задержку в 500 + ms. (В основном задержка хороша, но один от таких огромных латентного неприемлемо)Использование Boost :: Asio socket Просмотр 500ms в read

Я уже отключил алгоритм Нэк с помощью опции

_socket->set_option(tcp::no_delay(true)); 

Я пытался искать в Интернете, и, кажется, что есть и другие такие вещи, как Delayed Ack и флаг PUSH, которые могут обеспечить задержку.

Я использую Linux, установка флага PUSH, вероятно, недоступна в Linux. Не уверен в настройке Delayed Ack на BOOST. (Должен ли я использовать собственный дескриптор сокета, извлеченный из буфера расширения?)

Закрывая этот вопрос, задержка была со стороны приемника. Базовый протокол, реализованный между клиентом и сервером, таков, что получатель не передает флаг отправителю для отправки большего количества пакетов. Ничего там на уровне TCP. Внедрение уровня приложения плохое.

+3

Настоящий вопрос заключается в том, с чем вы соединяетесь с этим гнездом? Вполне возможно, что зависание находится на другом конце соединения, а не на вашем. –

+2

И как вы измерили эту задержку? Откуда он? – 2013-03-15 14:01:44

+1

И вы отключили алгоритм Нагле на стороне _sending_? Это не повлияет на принимающую сторону. Вы убедились, что отправляющая сторона действительно отправила данные? –

ответ

0

Задержка была со стороны приемника. Основной протокол, реализованный между клиентом и сервером, таков, что получатель не передает флаг отправителю для отправки большего количества пакетов. Ничего там на уровне TCP. Внедрение уровня приложения плохое. Закрытие этого вопроса.

Смежные вопросы