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

M>>>Вариант №1 вызываем epoll_ctl( EPOLLET + EPOLLIN+EPOLLOUT)
M>>>не буду получать нотификацию EPOLLIN до следующих принятых данных, если прочитаю не всё что есть в сокете.
M>>>Как понять, что я всё прочитал из сокета ?

V>>чтение вернет данных меньше чем размер предоставленного под чтение буфера, либо чтение вернет ноль данных и диагностику EAGAIN (сокет неблокирующий)
M>В этом можно быть уверенным ? Не может быть так что вернёт меньше и ещё останется ?
Прям четких гарантий я не встречал, но на практике оно ведет себя именно так.

M>>>Какие ещё есть решения ?

V>>Сделать адаптер из ET в LT.
V>>За базовый — берем ET. Для записи — используем его как есть.
V>>Для чтения — заводим дополнительный булевый флажок со смыслом "есть что читать", по умолчанию сброшен, при получении EPOLLIN — взводим, при неблокирующем чтении — если вычитано меньше данных нежели предоставленный под чтение буфер или вычитано 0 и выдана диагностика EAGAIN — сбрасываем. Чтение, естественно, неблокирующее, чтобы вместо блока был EAGAIN. Вот и все, булевый флажок в основном эквивалентен предикату "есть что читать", остается лишь малый кейс при котором это не так — если при очередном чтении было вычитано данных ровно под размер буфера и именно такое количество данных и было доступно.. Но, это легко отрулить.

M>Вопрос, что делать потом с эти флажком ? Заставить дочитать сокет до конца сейчас или после следующего вызова epoll_wait() ?

В смысле что делать с флажком? Это тебе признак того что "есть что читать" для того чтобы вести чтение по режиму LT при записи ET. Вот этот флажок и есть маркер LT для чтения. Если не взведен — данных нет, можно не читать, все равно не получится. Если взведен — читай если хочешь и получишь данные. Можешь дочитать до конца тогда флажок сбросится. Можешь не дочитывать до конца, тогда флажок останется взведенным и вэлкам почитать ещё если есть такое желание.

M>Я сейчас читаю всё до конца. Но мне не нравится такое решение — если будет клиент который шлёт много данных, я буду тратить на него много ресурсов и латентность приложения увеличится.
M>Я бы лучше читал по 8-32кб за 1 раз, потом epoll_wait() и снова читать то что недочитано. Мне кажетья таким способом латентность будет лучше, чем когда всё читать до конца.
Оставлять чтение на потом (вместо push модели переходить на pull) конечно можно, и этим, например, решаются вопросы пересыщения локальных буферов если входящий трафик превосходит возможности его обработки... Но про латентность не вполне понятно, что имеешь ввиду. Посмотри на TCP, какие у него буфера с одной и с другой стороны, что такое окно, на каких режимах все это хозяйство эффективно использует канал связи, какие эффекты канала убивают эффективность, какие алгоритмы управления окном бывают в TCP, как они себя ведут на том или ином типе трафика и канале связи..