<<
>>

Адресация

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

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

связываться с ТБАР для установки соединения с удаленным ТБАР.

Такие соединения проходят через КБАР на каждом хосте, как показано на рисунке. ТБАР нужны для того, чтобы различать конечные точки, совместно использующие ЫЗАР, в сетях, где у каждого компьютера есть свой КБАР.

Рис. 6.5. Точки доступа к службам транспортного и сетевого уровня и транспортные соединения

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

образом:

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

Например, может вызываться примитив, подобный LISTEN.

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

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

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

5. Транспортное соединение разрывается.

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

Нарисованная картинка всем хороша, но мы обошли стороной один маленький вопрос: как пользовательский процесс хоста 1 узнает, что сервер, сообщающий время, соединен с TSAP 1522? Возможно, сервер, сообщающий время, подключается к TSAP 1522 в течение долгих лет, и постепенно об этом узнают все пользователи сети. В этом случае службы имеют постоянные TSAP-адреса, хранящиеся в файлах, расположенных в известных местах, таких как etc/services в UNIX-системах. В файлах перечисляются серверы, за которыми жестко закреплены определенные порты.

Хотя постоянные TSAP-адреса могут хорошо подходить для небольшого количества никогда не меняющихся ключевых служб (например, таких как вебсервер), в общем случае пользовательские процессы часто хотят пообщаться с другими пользовательскими процессами, существующими только в течение короткого времени и не обладающими постоянными TSAP-адресами, известным всем заранее. Кроме того, при наличии большого количества серверных процессов, большая часть которых редко используется, слишком расточительным делом оказывается поддержка всех их в активном состоянии с постоянными TSAP-адресами. То есть требуется другая модель.

Одна такая модель показана в упрощенном виде на рис.

6.6. Она называется протоколом начального соединения. Вместо того чтобы назначать всем возможным серверам хорошо известные TSAP-адреса, каждая машина, желающая предоставлять услуги удаленным пользователям, обзаводится специальным обрабатывающим сервером, действующим как прокси (посредник) для менее активно используемых серверов. Он прослушивает одновременно несколько портов, ожидая запроса на соединение. Потенциальные пользователи этой услуги начинают с того, что посылают запрос CONNECT, указывая TSAP-адрес нужной им службы. Если никакой сервер их не ждет, они получают соединение с обрабатывающим сервером, как показано на рис. 6.6, а.

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

Хотя протокол начального соединения прекрасно работает с серверами, которые можно создавать по мере надобности, есть много ситуаций, в которых службы существуют независимо от обрабатывающего сервера. Например, файловый сервер должен работать на специальном оборудовании (машине с диском) и не может быть создан на ходу, когда кто-нибудь захочет к нему обратиться.

Чтобы справиться с этой ситуацией, часто используется другая схема. В этой модели используется специальный процесс, называющийся сервером имен или иногда каталоговым сервером. Чтобы найти TSAP-адрес, соответствующий данному имени службы, например «время суток», пользователь устанавливает соединение с сервером имен (TSAP-адрес которого всем известен). Затем пользователь посылает сообщение с указанием названия нужной ему услуги, и сервер

имен сообщает ему ТБАР-адрес этой службы. После этого пользователь разрывает соединение с сервером имен и устанавливает новое соединение с нужной ему службой.

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

Функция сервера имен аналогична работе оператора телефонной справочной службы — он преобразует имена в номера. Как и в телефонной системе, важно, чтобы ТБАР-адрес сервера имен (или обрабатывающего сервера в протоколе начального соединения) был действительно хорошо известен. Если вы не знаете номера телефонной справочной, вы не сможете позвонить оператору. Если вы полагаете, что номер справочной является очевидным, попытайтесь угадать его, находясь в другой стране.

<< | >>
Источник: Э. ТАНЕНБАУМ. КОМПЬЮТЕРНЫЕ СЕТИ 4-Е ИЗДАНИЕ. 2003

Еще по теме Адресация:

  1. § 7. Правоотношения из объявления публичного конкурса (п. 2543-2552)
  2. 2. Правовая охрана товарного знака (знака обслуживания)
  3. Это пишется иначе
  4. Л.О. Доліненко, В.О. Доліненко, С.О. Сарновська. Цивільне право України, 2006
  5. ЦИВІЛЬНЕ ПРАВО УКРАЇНИ
  6. ПЕРЕДМОВА
  7. Частина І ПРОГРАМА КУРСУ «ЦИВІЛЬНЕ ПРАВО УКРАЇНИ»
  8. Розділ І. Загальні положення цивільного права
  9. Тема 1. Поняття цивільного права. Предмет та метод, система цивільного права. Функції та принципи цивільного права
  10. Тема 2. Цивільне законодавство України
  11. Тема 3. Поняття, елементи та види цивільних правовідносин
  12. Тема 4. Здійснення цивільних прав і виконання обов’язків
  13. Тема 5. Захист цивільних прав та інтересів
  14. Тема 6. Об’єкти цивільних прав
  15. Тема 7.ФІЗИЧНІ особи як суб’єкти цивільного права
  16. Тема 8. Юридичні особи