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

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

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

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

Answer 3

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

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