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