Когда send () вернет аргумент длины меньше?

Question

При использовании блокирующих сокетов в Linux, есть ли причина для send(), чтобы вернуть меньше, чем было запрошено, другие , чем прерванный, но частично успешный send() системный вызов?

Я знаю, что это, возможно, очень определяется реализацией, и что было бы очень опасно полагаться на такое поведение даже без каких-либо установленных обработчиков сигналов (и, следовательно, причин для прерванных системных вызовов). Я, вероятно, переберу команду send call до завершения; однако, если бы было какое-либо официальное слово по этому вопросу, я мог бы избежать этого.

Почему предполагается, что send может возвращать с менее запрашиваемыми данными, переданными на блокирующем сокете? задавал тот же вопрос с неубедительными результатами: прерванные системные вызовы упоминаются в качестве примера для короткого подсчета возврата , но все еще неясно, будет ли полный буфер отправки TCP вызывать частичную отправку, или send() будет просто блокироваться, пока в буфере не будет достаточно места.

Answer 1

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

Теперь можно утверждать, что было бы более целесообразно блокировать (на блокирующем сокете), но причина этого не историческая - TCP основан на каналах UNIX, и именно так работали каналы UNIX.Основная причина в том, что это облегчает выполнение угловых случаев (в ядре) - вам не нужно беспокоиться о блокировке системного вызова in the middle для выполнения чего-либо;он либо что-то делает и возвращает немедленно, либо ничего не делает и блокирует до некоторого события (после чего ядро ​​повторяет попытку с нуля).Вам не нужно беспокоиться о том, что произойдет, если кто-то попытается записать больше, чем максимальный размер буфера за одну запись (что в противном случае может привести к взаимоблокировке).