Элементы транспортных протоколов. Адресация. Установка соединения. Разрыв соединения.

Адресация. Когда один прикладной процесс желает установить соединение с другим прикладным процессом, он должен указать, с кем именно он хочет связаться. (У не требующей соединений транспортной службы проблемы такие же: кому следует посылать каждое сообщение?) Применяемый обычно метод состоит в определении транспортных адресов, к которым процессы могут посылать запросы на установку соединения. В Интернете такие конечные точки называются портами. В сетях ATM это точки доступа к службе AAL-SAP. Мы будем пользоваться нейтральным термином TSAP (точка доступа к службам транспортного уровня). Аналогичные конечные точки сетевого уровня называются NSAP (точка доступа к сетевому сервису). Примерами NSAP являются IP-адреса.

Рисунок 6.5 иллюстрирует взаимоотношения между NSAP, TSAP и транспортным соединением. Прикладные процессы как клиента, так и сервера могут связываться с TSAP для установки соединения с удаленным TSAP. Такие соединения проходят через NSAP на каждом хосте, как показано на рисунке. TSAP нужны для того, чтобы различать конечные точки, совместно использующие NSAP, в сетях, где у каждого компьютера есть свой NSAP.

Возможный сценарий для транспортного соединения выглядит следующим образом:

1. Серверный процесс хоста 2, сообщающий время суток, подсоединяется к точке доступа TSAP 1522 и ожидает входящего звонка. Вопрос о том, как процесс соединяется с TSAP, лежит за пределами сетевой модели и целиком зависит от локальной операционной системы. Например, может вызываться примитив, подобный LISTEN.

2. Прикладной процесс хоста 1 желает узнать, который час, поэтому он обращается к сети с запросом CONNECT, указывая TSAP 1208 в качестве адреса отправителя и TSAP 1522 в качестве адреса получателя. Это действие в результате приводит к установке транспортного соединения между прикладным процессом хоста 1 и сервером 1, расположенным на хосте 2.

3. Прикладной процесс отправляет запрос, надеясь выяснить, который час.

4. Сервер обрабатывает запрос и в качестве ответа посылает информацию о точном времени.

5. Транспортное соединение разрывается. Обратите внимание на то, что на хосте 2 могут располагаться и другие серверы, соединенные со своими TSAP и ожидающие входящих запросов на соединение, приходящих с того же NSAP.

 

Установка соединения. Томлинсон (1975) предложил «тройное рукопожатие». Этот протокол установки соединения не требует, чтобы обе стороны начинали передачу с одинаковыми порядковыми номерами, поэтому он может применяться вместе с методами синхронизации. Нормальная процедура установки соединения показана на рисунке а.

Хост 1 инициирует установку, выбирая порядковый номер х, и посылает TPDU-модуль CONNECTION REQUEST, содержащий этот начальный порядковый номер, хосту 2.

 Хост 2 отвечает TPDU-модулем АСК, подтверждая х и объявляя свой начальный порядковый номер у.

Наконец, хост 1 подтверждает выбранный хостом 2 начальный порядковый номер в первом посылаемом им информационном TPDU-модуле.

Рассмотрим теперь работу «тройного рукопожатия» в присутствии задержавшегося дубликата управляющего TPDU-модуля.

На рис б первый TPDU-модуль представляет собой задержавшийся дубликат модуля CONNECTION REQUEST от старого соединения. Этот TPDU-модуль прибывает на хост 2 тайком от хоста 1. Хост 2 реагирует на этот TPDU-модуль отправкой хосту 1 TPDU- модуля АСК, таким образом прося хост 1 подтвердить, что тот действительно пытался установить новое соединение. Когда хост 1 отказывается это сделать, хост 2 понимает, что он был обманут задержавшимся дубликатом, и прерывает соединение.

Таким образом, задержавшийся дубликат не причиняет вреда. При наихудшем сценарии оба TPDU-модуля — CONNECTION REQUEST и АСК - блуждают по подсети. Этот случай показан на рис в.

Как и в предыдущем примере, хост 2 получает задержавшийся модуль CONNECTION REQUEST и отвечает на него. В этом месте следует обратить внимание на то, что хост 2 предложил использовать у в качестве начального порядкового номера для трафика от хоста 2 к хосту 1, хорошо зная, что TPDU-модулей, содержащих порядковый номер у, или их подтверждений в данный момент в сети нет. Когда хост 2 получает второй задержавшийся TPDU-модуль, он понимает, что это дубликат, так как в этом модуле подтверждается не у, a z. Здесь важно понять, что не существует такой комбинации TPDU-модулей, которая заставила бы протокол ошибиться и случайно установить соединение, когда оно никому не нужно.

 

Разрыв соединения.

Разорвать соединение проще, чем установить. Тем не менее, здесь также имеются подводные камни. Существует два стиля разрыва соединения: асимметричный и симметричный. Асимметричный разрыв с вязи соответствует принципу работы телефонной системы: когда одна из сторон вешает трубку, связь прерывается. При симметричном разрыве соединение рассматривается в виде двух отдельных однонаправленных связей, и требуется раздельное завершение каждого соединения.

На рисунке показаны четыре сценария разъединения, использующих «тройное рукопожатие». Хотя этот протокол и не безошибочен, обычно он работает успешно.

На рис а, показан нормальный случай, в котором один из пользователей

посылает запрос разъединения DR (DISCONNECTION REQUEST), чтобы инициировать разрыв соединения. Когда он прибывает, получатель посылает обратно также запрос разъединения DR и включает таймер на случай, если запрос потеряется. Когда запрос прибывает, первый отправитель посылает в ответ на него TPDU-модуль с подтверждением АСК и разрывает соединение. Наконец, когда прибывает АСК, получатель также разрывает соединение.    Разрыв соединения означает, что транспортная сущность удаляет информацию об этом соединении из своей таблицы открытых соединений и сигнализирует о разрыве соединения владельцу соединения (пользователю транспортной службы). Эта процедура отличается от использования пользователем примитива DISCONNECT.

Если последний TPDU-модуль с подтверждением теряется (рис. б), ситуацию спасает таймер. Когда время истекает, соединение разрывается в любом случае.

Теперь рассмотрим случай потери второго запроса разъединения DR. Пользователь, инициировавший разъединение, не получит ожидаемого ответа, у него истечет время ожидания, и он начнет все сначала. На рис. в показано, как это происходит в случае, если все последующие запросы и подтверждения успешно доходят до адресатов.

Последний сценарий (рис. г) аналогичен предыдущему — с той лишь разницей, что в этом случае предполагается, что все повторные попытки передать запрос разъединения DR также терпят неудачу, поскольку все TPDU-модули теряются. После N повторных попыток отправитель наконец сдается и разрывает соединение. Тем временем у получателя также истекает время, и он тоже разрывает соединение.

 

 

⇐ Предыдущая16171819202122232425Следующая ⇒

Поделиться: