Еще раз для непонятливых: буфер коммутатора не заполняется полностью из-за того, что сам протокол TCP регулирует отсылку сегментов. Ибо на каждый переданный TCP сегмент со стороны сервера, требуется подтверждающий пакет от клиента. Представь, что сервер подключен на скорости 100Мб, а клиент - на 10 мб. Клиент будет слать подтверждения серверу на скорости 10 мбит, следовательно скорость передачи от сервера к клиенту будет около 10 мбит (я не беру в расчет окно передачи TCP ибо как раз пакеты окна передачи TCP буферизируются коммутатором, но размер окна TCP намного меньше внутреннего буфера коммутатора.) И еще раз: коммутатор может дропать только UDP пакеты, т.к. они идут без подтверждения. Но сам UDP - протокол негарантированной доставки, поэтому большие объемы информации через него не передают.
RadioShark Вообще-то, по-моему, возможность приема кадра регулируется на порту коммутатора на уровне Ethernet, а не на уровне TCPIP. Если сетевая карта хочет передать в порт коммутатора кадр, а порт назначения занят, то коммутатор устанавливает запрет на передачу последующих кадров по этому порту. Интересно, как же, по Вашему, будет работать коммутатор, если в сети используется другой транспортный протокол (не TCPIP). :D :D А то, что протокол TCP работает с установлением соединения, со всяким там квитированием и т.д. - так это все идет уже поверх Eternet-а и коммутатор, по-большому, не волнует.
Сетевую карту не волнует занят ли порт назначения коммутатора или нет ибо коммутатор использует алгоритм "store and forward", т.е. сначала пакет от сетевой карты складывается в буфер, а потом перенаправляется на нужный порт. Ты может путать понятие "занятось" порта с коллизиями в Ethernet-хабе (не свитче!), когда сетевая карта не может отправить пакет из-за занятости среды передачи. Насчет других протоколом TCPIP - во-первых, они редко используются. Во-вторых, для передачи больших объемов информации всегда используются протоколы с квитированием, что затрудняет переполнение буфера коммутатора. В-третьих, если ты страдаешь паранойей, то можешь купить коммутатор с увеличенным объемом внутренного буфера.
RadioShark Ну, а если нужный порт, как тогда? Что, сетевая карта будет продолжать отправлять новые пакеты в коммутатор?!? Да ничего подобного! Коммутатор ей скажет "заткнись, пожалуйста". Ибо дуплекс. Dimm_On добавил [date]1082966675[/date]: Ничего я не путать. Если с двух портов коммутатора идет кадр в один и тот же порт назначения, тогда он и будет занят.
На физическом уровне - Ehternet. На этом-же уровне происходит коммутация в коммутаторе. Все остальное - поверх него. Ну может и не Eternet, а что-нибудь другое, TokenRing например. Вообще, коммутаторы так и называются: Коммутатор (Fast)Ethernet, TokenRing, ATM, а не TCP/IP. Собственно этим все и сказано. Dimm_On добавил [date]1082968693[/date]: И сетевые карты соответственно
хорошо, я перефразирую вопрос: какой управляющий пакет должен послать коммутатор сетевой карте, чтобы последняя прекратила передачу?
Этот ресурс очень полезен, несомненно. Но то, что там описано - вполне объяснимый трюк с коллизиями, который на практике редко будет работать, т.к. сам протокол TCP будет управлять потоком данных.
ага. а вообще читал твою беседу с RadioShark и плакалъ... Гадский Поттер добавил [date]1082974452[/date]: "IP-комутатор"... полный апофигей... запишу в книжечку... хотя зачем??? такое не забудешь... стопудова!
RadioShark Уважаемый! Протокол с организацией связи TCP создает виртуальный канал между приложениями!!! и на работу коммутатора никак не влияет. Понятие относится к возможности протокола TCP управлять загрузкой своего приемного буфера, если приложение, для которого идут данные - не успевает их обрабатывать (т.е. буфера протокола, а не коммутатора, елы-палы). Т.е. регулировкой занимается приемник протокола TCP. А если из-за затыков в коммутаторе пакеты вообще не приходят к приемнику - что тогда регулировать? К принципу коммутации пакетов в коммутаторе tcp flow control не имеет никакого отношения. АМИНЬ (это когда речь идет о вопросах веры, а не здравого смысла)