Накопление данных в буфере приема, чтобы предотвратить ожидание занятости при epoll_waiting на медленных соединениях

Question

Клиенты, отправляющие достаточно большой объем данных при достаточно медленном интернет-соединении, заставляют меня ждать ожидания в классической неблокирующей настройке сервер-клиент в C с сокетами.

Ожидание занятости вызывается вподробно с помощью этой процедуры

1. Я устанавливаю EPOLLIN для клиента, (монитор для получения данных)
2. клиент отправляет данные.
3. epoll_wait сигнализирует мне, что естьданные для чтения (EPOLLIN)
4. сопрограмма возобновляется, данные используются, для завершения работы этого клиента требуется больше данных. EWOULDBLOCK и ОБРАТНО к 1.

Эта процедура повторяется в течение нескольких минут (из-за медленного интернет-соединения и большого объема данных). По сути, это просто бесполезный скачок без каких-либо значимых действий, кроме как тратить время на процессор. Кроме того, это своего рода убивает цель epoll_wait.

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

Сначала я посмотрел на tcp (7) , я надеялсядля чего-то вроде TCP_CORK, но для буфера приема, но ничего не смог найти.

Затем я посмотрел на unix (7) и попытался реализовать его самостоятельно через SIOCINQ сразу послеШаг 3. Проблема в том, что я снова занят ожиданиями, потому что шаг 3. немедленно вернется, потому что данные доступны для чтения. В качестве альтернативы я мог бы отменить регистрацию клиента сразу после 3., но это заблокировало бы этого конкретного клиента до тех пор, пока epoll_wait не вернется с другого клиента.

Является ли это патовой ситуацией, или есть какое-либо решение вышеуказанной проблемы для накопленияданные в приемном буфере при минимальном размере или максимальном времени без ожидания занятости?

Answer 1

@ ezgoing и я долго об этом болтал, и я убежден, что это не проблема (как заметил и @ user207421).

Когда я впервые прочитал вопрос, я подумал, что, возможно, они былибеспокоятся о крошечных количествах (скажем, 16 байтов за раз), и это стоило бы исследовать, но как только выясняется, что это 4 КБ за раз, это настолько обычное дело, что это не стоит смотреть.

Интересно, что модуль последовательного ввода-вывода поддерживает это, с режимом, который активируется только после того, как столько символов доступно или прошло столько времени, но с сетевым модулем такого нет.

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