Что происходит, когда мне не удается вызвать `recv` достаточно быстро?
Я хочу объяснить возможный сценарий, когда клиенты моей службы сокетов потоков TCP/IP отправляют данные в мой сервис быстрее, чем ему удается переместить данные в свои буферы (я говорю о буферах приложений, естественно) с recv и работать с этим. В общем, что происходит в таких сценариях? Очевидно, что какой-то сервис под моим сервисом, который является пользовательским приложением, должен принимать входящий поток и сохранять его где-то до тех пор, пока я не выдам 'recv', верно? Скорее всего, операционная система. Я не хочу заново открывать старые вопросы, но я не могу найти ответ на этот, казалось бы, очевидный вопрос?
2 ответа
TCP обеспечивает управление потоком. Стек TCP (как на стороне отправителя, так и на стороне получателя) сможет буферизовать некоторые данные для вас, и это обычно делается в ядре ОС.
Когда буферы получателя заполняются, отправитель узнает об этом и прекратит отправку большего количества данных, что в конечном итоге приведет к блокировке отправляющего приложения (или, в противном случае, к невозможности отправки большего количества данных), пока пространство снова не станет доступным.
Вкратце, каждый отправленный TCP-пакет (сегмент) включает в себя размер данных, которые могут быть буферизованы - размер окна. Это означает, что другой конец всегда знает, сколько данных он может отправить без того, чтобы получатель не выбросил его, потому что буферы заполнены. Если размер окна становится равным 0, буферы заполнены, и данные больше отправляться не будут (а в случае блокировки отправителя send() вызов заблокирует), есть процедуры для проверки того, равно ли окно tcp 0, поэтому отправка может возобновиться, когда данные будут использованы.
Здесь есть еще несколько деталей