Что произойдет, если кто -то не назвал Posix `recv`« достаточно быстро »?

Question

Я хочу учесть возможный сценарий, в котором клиенты моей службы Socket Socket Socket Socket TCP/IP -потока отправляют данные в мою службу быстрее, чем ему удается перемещать данные в свои буферы (я говорю о буферах приложения, естественно) с recv и работать с этим.

Итак, что происходит в таких сценариях?

Очевидно, что какая -то обслуживание под моим сервисом, которое является пользовательским приложением, должен получить входящий поток и хранить его где -то, пока я не выпущу «Recv», верно? Наверняка операционная система.

Я не хочу вновь открывать старые вопросы, но я не могу найти ответ на этот, казалось бы, очевидный?

Answer 1

TCP предоставляет управление потоком Анкет Стек TCP (как на стороне отправителя, так и на стороне приемника) сможет буферизировать некоторые данные для вас, и это обычно делается в ядре ОС.

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

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

Есть несколько подробностей здесь

Answer 2

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