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

Question

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

Answer 1

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

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

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

Здесь есть некоторые подробности здесь

Answer 2

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