Р.Л. Смелянский - Компьютерные сети. Том 2. Сети в ЭВМ (1130083), страница 25
Текст из файла (страница 25)
Если требуемое -;:".!!,:.:качество недостижимо, то транспортный уровень сразу сообщает об «:.;:этом приложению-отправителю, указывая причины неудачи. При ~;;,:-::::; этом приложению-получателю ничего не сообщается. Процедура со- -«~., Гласования параметров качества сервиса называется согласованием :.!«т~,:.:: возможностей. 3. 1.3. Примитивы трвнспортното уровня Примитивы транспортного уровня открывают пользователю до:.~=;,.;: ступ к транспортному сервису. Транспортный сервис аналогичен :„"",,:::.сервису сетевого уровня. Однако между ними существует одно раз„"":.!';, личие; качеством сервисов сетевого уровня, включая надежность ;;~:;-:;:Передачи, на прикладном уровне управлять нельзя.
Сетевой уровень ;::~~':. Принадлежит транспортной среде, которую прикладной уровень кон- .~;;::;;.!",пропировать не может. Задача транспортного сервиса как раз в том и .!:,'„. состоит, чтобы обеспечить доставку сообгдений с качеством, заданным .:; приложением. Два процесса прикладного уровня, соединенные между ',-.„".;:.;;-::особой, ничего не должны знать о том, как физически они соединены ".';,-'; Один помещает данные на вход транспортного уровня, другой по;;,": лучает их.
Задача транспортного уровня скрыть и от получателя, и от ";ь отправителя все детали передачи, исправления ошибок и т. и Теоретически транспортный сервис может быть как ориентиро";, Ванным на соединения, так и не ориентированным на соединения Однако дейтаграммный транспортный сервис — это редкость, поэтоМу мы будем рассматривать транспортный сервис, ориентированный - На соединения Другое важное различие между сетевым и транспортным сервисаМи заключается в их применении: сетевой сервис используется транс- 107 портным сервисом, а транспортный сервис используется прикладными программами.
Транспортный сервис должен быть ориентирован на пользователя, т. е, быть удобным и простым в применении. Примитивы транспортного уровня аналогичны примитивам сетевого уровня. Общее представление о примитивах транспортного сервиса дадим с помоцгью следуюшего примера.
Сервер приложения выполняет примитив Е!ЯТЕ1х1, в результате чего он блокируется до поступления запросов от клиентов. Клиент для установления соединения выполняет примитив СОМХ ЕСТ. Транспортный агент на стороне клиента блокирует клиента и посылает серверу пакет с запросом на установление соединения. Напомним, что транспортные агенты обмениваются пакетами, имеющими специальное название — ТРО~/ (Тгапарог! Рго!осо! !За!а 13п!!), которые мы будем называть сегментами. По примитиву СОХМЕСТ транспортный агент со стороны клиента посылает сегмент СОМй!ЕСТ101х! ВЕО!3ЕЯТ. Транспортный агент сервера, увидев, что сервер заблокирован по примитиву 1-1ЯТЕХ, разблокирует сервер и посылает сегмент СОМХЕСТ1О1ч АССЕРТЕО.
После этого транспортное соединение считается установленным и начинается обмен данными с помощью примитивов ЯЕ1х!Т и ВЕС Е1ЧЕ. По окончании обмена данными транспортное соединение должно быть разорвано. Есть два варианта разрыва соединения; асимметричный и симметричный. Асимметричный разрыв предполагает, что для разрыва соединения только одна из сторон посылает сегмент Р!ЯСО1чХЕСТ. Сторона, получившая такой ТРО13-сегмент, считает соединение разорванным, При симметричном разрыве каждая сторона закрывает соединения отдельно, и только после этого соединение считается разорванным. Когда одна сторона посылает сегмент Р1ЯСО!х!МЕСТ, это означает, что с ее стороны больше данных не будет.
На рис. 3.! показана диаграмма состояний при установлении и разрыве соединения. В табл. 3.1 показан другой набор примитивов — это так называемые сокеты Беркли. В этом наборе имеется два основных отличия от того, что мы рассмотрели ранее. Первые четыре примитива выполняются сервером в том порядке, в каком они указаны в таблице.
Примитив 5ОСКЕТ создает структуру данных по определенному шаблону для подключения к серверу, резервируя для нее место в таблице транспортного агента. Параметры обрашсния определяют формат адреса, тип желаемого сервиса, протокол и т.д. По примитиву В1!МО сервер выделяет сокету адрес. Причина, по которой адрес выделяется не сразу, состоит в том, что некоторые процессы сами управляют своим адресным пространством, жестко закрепленным за ними.
Примитив ! !ВТЕКИ не является блокирующим, он выделяет !08 "уа.'„",:Л Получен ТРОП запроса на соелинение ! ! Пассивное ожидание установления соединения Выполнен примитив СОХХЕСТ Получен ТРО на разрыв со ! Выповнен примитив О!ЯСОХХЕСТ Рис. 3.1. Диапзамм ,~.::,::,,': ресурсы и создает '::!~:.;":.;::ся за соединением '.";,':,":. в,ся блокирующим а состояний при установлении и разрыве соелинения очередь, если несколько клиентов будут обращать- в одно и то же время. Примитив АССЕРТ являет- в ожидании запроса на соединение. Таблица 3.1 Сокеты Беркли Значение Примитив Создание новой точки подключения БОСКЕТ Прикрепление локального адреса к сокету В1ХР Е1ЯТЕХ Блокировка вызывающего в ожидании запроса на соедине- ние АССЕРТ СОХ Х ЕСТ Активная попытка установления соединения Отправка данных через данное соединение БЕХР ЙЕСЕ1УЕ Получение данных через данное соединение СЕРБЕ Разрыв соединения 1б9 Объявление готовности принимать соединения; сообщение о размере очереди Когда клиент выполняет примитив СОХ1ЧЕСТ, он блокируется своим транспортным агентом, и процесс установления соединения запускается.
Когда этот процесс закончится, клиент разблокируется, и начинается обмен данными с помощью примитивов ЯЕХР и КЕСЕ!Ъ'Е, Разрыв соединения здесь симметричен, т.е. соединение считается разорванным, если обе стороны выполнили примитив СЕОЯЕ. 3.2. Элементы транспортного протокола 3.2. 1. Общие сведения Транспортный сервис реализуется транспортным протоколом, который используют транспортные агенты. Транспортный протокол в чем-то аналогичен канальному.
Однако между этими протоколами имеется несколько существенных различий: ° машины, взаимодействующие по канальному протоколу, соединены физическим каналом, в то время как транспортные агенты разлеляет сколь угодно длинная цепочка маршрутизаторов и мостов; ° процессзя на канальном уровне взаимодействуют непосредственно через общий канал, поэтому процедура установления соединения здесь намного проще, чем на транспортном; ° среда, в которой работает транспортный протокол, использует память маршрутизаторов, которая может терять свое содержимое; ° число соединений, которые могут возникать на транспортном уровне, намного больше, чем число соединений на канальном уровне, что создает дополнительные проблемы для буферизации и управления потоком. Транспортный протокол должен обеспечивать решение слелуюших вопросов; 1. Как адресовать прикладной процесс, с которым необходимо установить соединение? 2.
Как корректно установить соединение? Поскольку сегменты могут теряться, как отличить сегменты нового соединения от повторных сегментов, оставшихся от старого соединения? 3. Как корректно разрывать соединение'? Рассмотрим последовательно сугпествуюгцие решения для этих проблем. Проблема адресации состоит в том, как указать на транспортном уровне, с каким удаленным прикладным процессом требуется установить соединение. Обычно для этого используется транспортный адрес, по которому приклалной процесс может слушать запросы на 11О Хост 2 Хост 1 ' а .":зуд ';:::"цес :.=х 1РО ,: '~пр :-':;1 «Пр '."зма ',."-зап ,-; вы '-", вер .;.; сер Физическая среда Рис.
3.2. Взаимосвязь ТИАР и 1Ч ВАР 111 динение. Вместо транспортного адреса мы будем здесь использоь понятие Тгапзрог1 Бегх1се Ассезз Ро1пг — ТИАР. Напомним что, алогичное понятие существует и на сетевом уровне — 1Р-адрес, или АР для сетевого уровня. На рис. 3.2 показана взаимосвязь ТИАР и о15АР, а также сценарий пользования ТИАР для установления соединения между двумя аленными процессами. Из рис. 3.2 неясно только, как прикладной процесс на машине 1 ает, что интересующий его сервер подключен к ТИАР 122 на мане 2. Возможно, что, если данный сервер всегда подключен к ТИАР , все процессы об этом знают.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
