40. Транспортная служба. Примитивы транспортной службы.
Функции транспортного уровня состоят в установлении транспортного соединения между точками доступа, транспортировке данных по этому соединению, управлении потоком данных, исправлении ошибок транспортировки. Эти функции реализуются на трех разных этапах: этапе установления соединения, этапе переноса данных и этапе терминации соединения.
Примитивы транспортной службы.
Чтобы пользователи могли получить доступ к транспортной службе, транспортный уровень должен совершать некоторые действия по отношению к прикладным программам, т е предоставлять интерфейс транспортной службы. У всех транспортных служб есть свои интерфейсы.
Примитивы:
LISTEN (ОЖИДАТЬ) –Блокировать сервер, пока какой-либо процесс не попытается соединиться
CONNECT (СОЕДИНИТЬ) - ЗАПРОС СОЕДНИНЕНИЯ. Активно пытаться установить соединение.
SEND (ПОСЛАТЬ) – ДАННЫЕ. Послать информацию
RECEIVE (ПОЛУЧИТЬ) – Блокировать сервер, пока не прибудут данные
DISCONNECT (РАЗЪЕДИНИТЬ) – ЗАПРОС РАЗЪЕДИНЕНИЯ. Прервать соединение.
Чтобы понять, как могут быть использованы эти примитивы, рассмотрим приложение, состоящее из сеpвеpа и нескольких удаленных клиентов. Вначале сервер выполняет примитив LISTEN — обычно для этого вызывается библиотечная процедура, которая обращается к системе. В результате сервер блокируется, пока клиент не обратится к нему. Когда клиент хочет поговорить c сервером, он выполняет приметив CONNECT. Транспортный объект выполняет этот примитив, блокируя обратившегося к нему клиента и посылая пакет серверу. Поле даннх пакета сожержит сообщение транспортного уровня, адресованное транспортному объекту сервера.
Следует сказать пару слов o терминологии. За неимением лучшего термина, для сообщений, посылаемых одной транспортной сущностью другой транспортной сущности, нам придется использовать несколько неуклюжее сокращение TPDU (Transport Protocol Data Unit —модуль данных транспортного протокола). Модули данных, которыми обмениваются транспортные уровни, помещаются в пакеты (которыми обмениваются сетевые уровни). Эти пакеты, в свою очередь, содержатся в кадрах, которыми обмениваются уровни передачи данных. Получив кадр, уровень передачи данных обрабатывает заголовок кадра и передаёт содержимое поля полезной нагрузки кадра наверх, сетевой сущности. Сетевая сущность обрабатывает заголовок пакета и передаёт содержимое поля полезной нагрузки пакета наверх, транспортной сущности. Эта вложенность проиллюстрирована на рис. :
Итак, вернемся к нашему примеру общения клиента и сервера. B результате запроса клиента CONNECT серверу посылается модуль данных тpaнспоpтнoгo протокола, содержащий CONNECTION REQUEST (запрос соединения). Когда он пpибывает, транспортная сущность проверяет, заблокирован ли сервер пpимитивом LISTEN (то есть заинтересован ли сеpвеp в обработке запросов). Затем она разблокирует сервер и посылает обратно клиенту модуль данных CONNECTION ACCEPTED (соединение принято). Получив этот модуль, клиент разблокируется, после чего соединение считается установленным.
Теперь клиент и сервер могут обмениваться данными с помощью примитивов SEND и RECEIVE. В простейшем случае каждая из сторон может использовать блокирующий примитив RECEIVE для перехода в режим ожидания модуля данных, посылаемого противоположной стороной при помощи примитива SEND. Когда модуль данных пpибывaет, получатель разблокируется. Затем oн может обработать полученный модуль и послать ответ. Такая схема прекрасно работает, пока обе стороны помнят, чей чеpед посылать, а чей — принимать.
Обратите внимание на то, что на сетевом уровне даже простая однонаправленная пересылка данных оказывается сложнее, чем на транспортном уровне. Каждый пocлaнный пакет данных будет, в конце концов, подтвержден. Пакеты, содержащие управляющие модули данных, также подтверждаются, явно или неявно. Эти подтверждения управляются транспортными сущностям при помощи протокола сетевого уpовня и не видны пользователям транспортного уровня. Аналогично транспортным сущностям нет необходимости бecпокоиться о таймерах и повторных передачах. Все эти механизмы не видны пользователям транспортного уровня, для которых соединение представляется надёжным битовым каналом. Один пользователь помещает в канал биты, которые появляются на другом конце канала. Эта способность скрывать сложность от пользователей свидетельствует о том, что многоуровневые протоколы являются довольно мощным инструментом.
Когда соединение больше не требуется, оно должно быть разорвано, чтобы можно было освободить место в таблицах двух транспортных сущностей. Разъединение существует в двух вариантах: симметричном и асимметричном. В асимметричном варианте любой пользователь транспортной службы может вызвать примитив DISCONNECT, в результате чего удаленной транспортной сущности будет послан управляющий модуль TDU DISCONNECTION REQUEST (запрос разъединения). После получения модуля TPDU удаленной транспортной сущностью соединение разрывается.
B симметричном варианте каждое направление закрывается отдельно, независимо от другого. Когда одна сторона выполняет примитив DISCONNECT, это означает, что у нее больше нет данных для передачи, но что она все еще готова принимaть данные от своего партнера. В этой схеме соединение разрывается, когда обе стороны выполняют примитив DISCONNECT.
Диаграмма состояний для установки и разрыва соединения показана на рис. 6.3. Каждый переход вызывается каким-то событием или примитивом, выполненным локальным пользователем транспортной службы или входящим пакетом. Для простоты мы будем считать, что каждый модуль TPDU подтверждается отдельно. Мы также предполагаем, что используется модель симметричного раъединения, в которой клиент делает первый ход.
