Э. Таненбаум - Компьютерные сети. (4-е издание) (DJVU) (1130092), страница 155
Текст из файла (страница 155)
В результате получается полуоткрытое соединение, Этой ситуации можно было бы избежать, если не позволять отправителю сдаваться после У повторных попыток, а заставить его продолгкать попытки, пока не будет получен ответ. Однако если другой стороне будет разрешено разрывать связь по таймеру, тогда отправитель действительно будет вечно повторять попытки, так как ответа он не получит никогда.
Если же получающей стороне также не разрешать разрывать соединение по таймеру, тогда протокол зависнет в ситуации, изображенной на рис. 6.11, г. Чтобы удалять полуоткрытые соединения, можно применять правило, гласящее, что если по соединению в течение определенного времени не прибывает ни одного ТРьг11-модуля, соединение автоматически разрывается. Таким образом, если одна сторона отсоединится, другая обнаружит отсутствие активности и также отсоединится. Для реализации этого правила каждая сторона должна управлять таймером, перезапускаемым после передачи каждого ТРРг11-модуля, Если этот таймер срабатывает, посылается пустой ТР?И3-модуль — лишь для того, чтобы другая сторона не повесила трубку.
С другой стороны, если применяется правило автоматического разъединения и теряется слишком большое количество ТР1г11-модулей подряд, то соединение автоматически разрывается сначала одной стороной, а затем и другой. На этом мы заканчиваем обсуждение этого вопроса, но теперь должно быть ясно, что разорвать соединение без потери данных не так просто, как зто кажется на первый взгляд. Управление потоком и буферизация Изучив процессы установки и разрыва соединения, рассмотрим, как происходит управление соединением во время его использования.
Одним из ключевых вопросов, уже обсуждавшихся ранее, является управление потоком. В некоторых аспектах проблема управления потоком на транспортном уровне аналогична той же проблеме на уровне передачи данных, но в то гке время они различаются по целому ряду аспектов. Основное сходство состоит в том, что па обоих уровнях для согласования скорости передатчика и приемника требуется некая схема, например протокол скользящего окна. Основным различием является то, что у маршрутизатора обычно относительно небольшое количество линий, тогда как хост может иметь большое число соединений.
Из-за этого различия использование на транспортном уровне стратегии буферизации, применяемой на уровне передачи данных, является непрактичным. В протоколах передачи данных, обсуждавшихся в главе 3, кадры буферировались как отправляющим, так и получающим маршрутизаторами. Например, в протоколе 6 и отправитель, и получатель должны были отвести по МАХ БЕЯ+ 1 буферов для каждой линии — половину для входного потока, половину для выходного. Так, для хоста с максимальным количеством соединений, равным 64, и 4-битовым порядковым номером этот протокол потребует 1024 буфера.
578 Глава 6. Транспортный уровень На уровне передачи данных отправитель должен буферизировать выходные кадры, так как может понадобиться их повторная передача. Если подсеть предоставляет дейтаграммные услуги, отправляющая транспортная сущность должна также использовать буфер по той же самой причине. Если получатель знает, что отправитель хранит в буферах все ТР1ИЗ-модули до тех пор, пока они не будут подтверждены, тогда получатель сможет использовать свои буферы по своему усмотрению.
Например, получатель может содержать единый буферный накопитель, используемый всеми соединениями. Когда приходит ТРРП-модуль, предпринимается попытка динамически выделить ему новый буфер. Если это удается, то ТРОП-модуль принимается, в противном случае он отвергается. Поскольку отправитель готов к тому, чтобы передавать потерянные ТРРП-модули повторно, игнорирование ТРРП-модулей получателем не наносит вреда, хотя и расходует некоторые ресурсы. Отправитель просто повторяет попытки до тех пор, пока не получит подтверждения.
В итоге, если сетевая служба является ненадежной, отправитель должен буферизировать все посланные ТРРП-модули, как и на уровне передачи данных. Однако при надежной сетевой службе возможны другие варианты. В частности, если отправитель знает, что у получатели всегда есть место в буфере, ему не нужно хранить копии посланных ТРПУ-модулей. Однако если получатель не может гарантировать, что каждый приходящий ТРОП-модуль будет принят, получателю придется буферизировать посланные ТРОП-модули.
В последнем случае отправитель не может доверять подтверждениям сетевого уровня, так как они означают лишь то, что ТР1Н5-модуль прибыл, но не означают, что он был принят. Позднее мы вернемся к этому важному пункту. Даже если получатель соглашается буферизовать принимаемые ТРР11-модули, остается вопрос о том, какого размера должен быть буфер. Если большинство ТРРУ-модулей имеют примерно одинаковые размеры, естественно организовать буферы в виде массива буферов равной величины, каждый из которых может вместить один ТР1Н1-модуль, как показано на рис. 6.12, а. Однако если ТРЕПЗ- модули сильно различаются по размеру — от нескольких символов, набранных на терминале, до нескольких тысяч символов при передаче файлов, — то массив из буферов фиксированного размера окажется неудобным.
Если размер буфера выбирать равным наибольшему возможному ТРОП-модулю, то при хранении небольших ТРРП-модулей память будет расходоваться неэффективно. Если же сделать размер буфера меньшим, тогда для хранения большого ТРПУ-модуля потребуется несколько буферов с сопутствующими сложностями. Другой метод решения указанной проблемы состоит в использовании буфеРов переменного размера, как показано на рис, 6.12, б. Преимущество этого метода заключается в более оптимальном использовании памяти, но платой за это является усложненное управление буферами. Третий вариант состоит в выделении соединению единого большого циклического буфера, как показано на рис.
6.12, в Такая схема также довольно хорошо использует память, если все соединения сильно нагружены, однако при невысокой нагрузке некоторых соединений ее эффективность снижается. Элементы транспортных протоколов 579 ТР(З() 1 ТР0() 2 тр()() з трон в Неиспольз памят Рис. 6Л 2.
Цепочка буферов фиксированного размера (в); цепочка буферов фиксированного размера (б); один большой циклический буфер для одного соединения (в) Выбор компромиссного решения между буферизацией у отправителя и у получателя зависит от типа трафика соединения, Если трафик импульсный, небольшой мощности, как, например, трафик интерактивного терминала, лучше не выделять никаких буферов, а получать их динамически на обоих концах.
Так как отправитель не уверен, что получатель сможет получить буфер, он должен будет сохранять копию ТР1Н)-модуля, пока не получит относящееся к нему подтверждение. С другой стороны, при передаче файла будет лучше, если получатель выделит целое окно буферов, чтобы данные могли передаваться с максимальной скоростью. Таким образом, при пульсирующем трафике малой мощности буферизацию лучше производить у отправителя, а для графика с постоянной большой скоростью — у получателя. При открытии и закрытии соединений и при изменении формы трафика отправитель и получатель должны динамически изменять выделенные буферы. Следовательно, транспортный протокол должен позволять отправителю посылать запросы на выделение буфера на другом конце.
Буферы могут выделяться для каждого соединения или коллективно на все соединения между двумя хостами. В качестве альтернативы запросам буферов получатель, зная состояние своих буферов, но не зная, какой трафик ему будет предложен, может сообщить отправителю, что он зарезервировал для него Х буферов, При увеличении числа открытых соединений может потребоваться уменьшить количество или размеры выделенных буферов. Протокол должен предоставлять такую возможность.
В отличие от протоколов скользящего окна, описанных в главе 3, для реализации динамического выделения буферов следует отделить буферизацию от подтверждений. Динамическое выделение буферов означает, на самом деле, использование окна переменного размера. Вначале отправитель, основываясь на своих 580 Глава б. Транспортный уровень А Сообщение В Комментарии 1 -В. 2 3 -и 4 -В. 5 -В Я хочет 8 буферов М вЂ” В позволяет переспать только сообщения 0-3 У Я теперь осталось 3 буфера -В У Я теперь осталось 2 буфера Сообщения потерялось, но Я думает, что у него остался 1 буфер — В подтверждает получение модулей О и 1, разрешает передать со 2-го по 4-й — У Я остался буфер — > У Я осталось О буферов, и он должен остановиться — В У Я истекло время ожидания, и он передает еще рвз 4 — Все модули подтверждены, и он должен остановиться  — Теперь Я может послать мццуль 5 — В где-то нашел новый буфер У Я остался 1 буфер -> Я снова блокирован < — Я все еще блокирован — Потенииальный тупик < гециез! 8 Ьинегз> <асх = 15, Ьи! = 4> <зец = О, бага = вб> <зец = 1, дага = в1> <зец = 2, ба!а = в2> 6 ~ — <вся=1,Ьиг=з> 7 8 — в 8 10 «В- 11 «В— 12 13 — в 14 15 16 ° ° ° <зец = 3, бв!а = вз> <зец = 4, Оа!а = в4> <зец = 2, Оа!а = в2> <вся =4, Ьси= 0> <асх = 4, Ьит = 1> <ась = 4, ЬШ = 2> <зец = 5, Оа!а = в5> <зец = 6, Оа!а = вб> <асх = «аса = 6, Ьиг = О> 6, Ьси = 4> Рис.
6.13. динамическое выделение буферов. Стрелками показано направление передачи. Многоточие (...) означает потерянный Трой-модуль потребностях, запрашивает определенное количество буферов. Получатель выделяет столько, сколько может. При отправлении каждого ТР1П~-модуля отправитель должен уменьшать на единицу число буферов, а когда это число достигнет нуля, он должен остановиться. Получатель отправляет обратно на попутных ТРРП-модулях отдельно подтверждения и информацию об имеющихся у него свободных буферах. На рис.
6.13 показан пример управления динамическим окном в дейтаграммной подсети с 4-битными порядковыми номерами. Предположим, что запрос на предоставление буферов пересылается в отдельных ТРШ3-модулях, а не добирается <автостопом» на попутных модулях. Вначале хост А запрашивает 8 буферов, но ему выделяется только 4. Затем он посылает три ТРПА-модуля, из которых последний теряется. На шаге 6 хост А получает подтверждение получения посланных им ТРТН5-модулей 0 и 1, разрешает хосту А освободить буферы и послать еше три модуля !с порядковыми номерами 2, 3 и 4).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
