Нет, объект Stream, возвращаемый GetResponseStream , не буферизуется.
Краткий ответ на вторую часть (о настройке точки останова) состоит в том, что ваш сотрудник неверен.Сетевой трафик остановится, но, в конце концов, и для описания «в конце концов», читайте дальше для более подробной информации.
Bing для «SO_RCVBUF», «Размер окна приема tcp», «Автоматическое масштабирование перспективы»", для еще более общей информации.
Детальная часть
Начнем с этого, вот текстовое представление сетевого стека Windows:
++ .NET Network API's
++ --- Winsock DLL (пользовательский режим)
++ ------ afd.sys (режим ядра)
++ --------- tcpip.sys
++ ------------ ndis
++ --------------- сетевой интерфейс (hal)
Это грубый стек, приукрашивающий некоторые детали, но общая идея заключается в том, что .NET вызывает Winllck в пользовательском режиме dll, который затем выталкивает большинствонастоящая работа его двоюродного брата AFD (Драйвер вспомогательных функций), далее в подсистему tcpip, и т. д.
На уровне AFD естьбуфер, обычно между 8K и 64K , но с Vista (и beyond), он также может увеличиваться.Этот параметр также может управляться параметром реестра ( HKLM \ SYSTEM \ CurrentControlSet \ services \ AFD \ Parameters ).
Кроме того, tcpip.sys также имеет буфер, то естьпохож на буфер AFD.Я полагаю, что параметр * SO_RCVBUF *, переданный при открытии сокета, также может изменить это.
По сути, когда вы получаете данные, tcpip.sys от вашего имени продолжает получать данные и сохраняет сообщениеотправитель, который получил данные ( ACK ), и делает это до тех пор, пока его буферы не будут заполнены.Но в то же время afd.sys очищает буферы tcpip.sys , запрашивая данные (которые затем копирует в свой собственный буфер), поэтому tcpip.sys может заполнить больше данных от отправителя.
А вот и вы (вызывающий .NET API), который также делает то же самое, вызывает метод Read () и копирует данные в ваш буфер.
Итак, если вы подумаете об этом, сообщение 256Kb приходит по проводам, 64K в буфере tcpip.sys , 64K в буфере afd.sys и вы устанавливаете точку останова после запроса одного 4K (вашей переменной bufferSize) чанка, мы смотрим на ACK, переданный 128K, обратно отправителю, как получено, и так как буфер tcpip.sys заполнен (принимая размер 64 КБ) (и вы заблокированы сеансом отладки), tcpip.sys не будет иметь другого выбора, кроме как сказать отправителю прекратить отправку байтов по проводам, потому что он не может обработатьдостаточно быстро.
Практически (т.е. кто-то не настраиваетРеакпоинт!), я видел GC, чтобы вызвать такое поведение.Видел случай 3-секундной сборки мусора, которая позволяла заполнить все буферы ОС.