поведение сокета при чтении

Question

клиент записывает 5 байтов в сокет через каждую 1 секунду. сервер постоянно читает из сокета. буфер на стороне сервера имеет длину 10 байт. так что функция выглядит так

 read(fd, buf, 10);

сервер читает 5 байтов каждый раз.

теперь клиент пишет 5 байтов непрерывно. сервер такой же. сервер читает 10 байтов каждый раз.

так что чтение в сокете возвращает столько байтов, сколько доступно в буфере. он не ждет, чтобы заполнить буфер.

это как-то связано с SO_RCVLOWAT. я читал, что эта опция сокета влияет только на select / poll io.

спасибо

обновление

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

но я не могу установить нижний водяной знак на 0. Он всегда устанавливает его на 1 в этом случае. почему так?

Answer 1

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

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

Answer 2

Если вы хотите заполнить 10-байтовый буфер, вы можете установить SO_RCVLOWAT в 10, и он должен работать просто отлично.

poll / select будет сигнализировать сокет как читаемый, даже если нет доступных SO_RCVLOWAT байтов (по крайней мере, в Linux). Если вы собираетесь использовать свой сокет с poll / select, имейте в виду, что вызов read / recv / etc ... после poll / select может блокироваться, пока не будет доступно SO_RCVLOWAT число байтов.

Answer 3

Если вы не установили неблокирующий ввод / вывод, тогда вызов read () будет ожидать, пока все запрошенные вами байты не станут доступны или в сокете произошла ошибка.

Если вы установили неблокирующий ввод / вывод, тогда нет гарантии, что вы даже получите 5 байтов - вы можете получить одно чтение с 2 и одно с 6 - это зависит от системы и синхронизации сети.