2.2. Адресация
Когда один прикладной процесс желает установить соединение с другим при- кладным процессом, он должен указать, с кем именно он хочет связаться. (У не требующей соединений транспортной службы проблемы такие же: кому следует посылать каждое сообщение?) Применяемый обычно метод состоит в определе- нии транспортных адресов, к которым процессы могут посылать запросы на уста- новку соединения. В Интернете такие конечные точки называются портами. В се- тях ATM это точки доступа к службе AAL-SAP (Service Access Point). Мы будем пользоваться нейтральным термином TSAP (Transport Service Access Point — точка доступа к службам транспортного уровня). Аналогичные конечные точки сетевого уровня называются NSAP (Network Service Access Point — точка досту- па к сетевому сервису). Примерами 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. Нарисованная картинка всем хороша, но мы обошли стороной один малень- кий вопрос: как пользовательский процесс хоста 1 узнает, что сервер, сообщаю- щий время, соединен с TSAP 1522? Возможно, сервер, сообщающий время, под- ключается к TSAP 1522 в течение долгих лет, и постепенно об этом узнают все пользователи сети. В этом случае службы имеют постоянные TSAP-адреса, хра- нящиеся в файлах, расположенных в известных местах, таких как etc/services в UNIX-системах. В файлах перечисляются серверы, за которыми жестко закреп- лены определенные порты. Хотя постоянные TSAP-адреса могут хорошо подходить для небольшого ко- личества никогда не меняющихся ключевых служб (например, таких как веб- сервер), в общем случае пользовательские процессы часто хотят пообщаться с другими пользовательскими процессами, существующими только в течение ко- роткого времени и не обладающими постоянными TSAP-адресами, известным всем заранее. Кроме того, при наличии большого количества серверных процес- сов, большая часть которых редко используется, слишком расточительным де- лом оказывается поддержка всех их в активном состоянии с постоянными TSAP-адресами. То есть требуется другая модель. Одна такая модель показана в упрощенном виде на рис. 6.6. Она называется протоколом начального соединения. Вместо того чтобы назначать всем возмож- ным серверам хорошо известные TSAP-адреса, каждая машина, желающая пре- доставлять услуги удаленным пользователям, обзаводится специальным обраба- тывающим сервером, действующим как прокси (посредник) для менее активно используемых серверов. Он прослушивает одновременно несколько портов, ожидая запроса на соединение. Потенциальные пользователи этой услуги начи- нают с того, что посылают запрос CONNECT, указывая TSAP-адрес нужной им службы. Если никакой сервер их не ждет, они получают соединение с обрабаты- вающим сервером, как показано на рис. 6.6, а. Получив запрос, обрабатывающий сервер порождает подпроцесс на запрошен- ном сервере, позволяя ему унаследовать существующее соединение с пользовате- лем. Новый сервер выполняет требуемую работу, в то время как обрабатывающий сервер возвращается к ожиданию новых запросов, как показано на рис. 6.6, б. Хотя протокол начального соединения прекрасно работает с серверами, кото- рые можно создавать по мере надобности, есть много ситуаций, в которых служ- бы существуют независимо от обрабатывающего сервера. Например, файловый сервер должен работать на специальном оборудовании (машине с диском) и не может быть создан на ходу, когда кто-нибудь захочет к нему обратиться. Чтобы справиться с этой ситуацией, часто используется другая схема. В этой модели используется специальный процесс, называющийся сервером имен или иногда каталоговым сервером. Чтобы найти TSAP-адрес, соответствующий дан- ному имени службы, например «время суток», пользователь устанавливает со- единение с сервером имен (TSAP-адрес которого всем известен). Затем пользо- ватель посылает сообщение с указанием названия нужной ему услуги, и сервер имен сообщает ему TSAP-адрес этой службы. После этого пользователь разры- вает соединение с сервером имен и устанавливает новое соединение с нужной ему службой.
В этой модели, когда создается новая служба, она должна зарегистрироваться на сервере имен, сообщив ему название услуги (обычно строка ASCII) и TSAP-ад- рес. Сервер имен сохраняет полученную информацию в своей базе данных, что- бы иметь возможность отвечать на будущие запросы. Функция сервера имен аналогична работе оператора телефонной справочной службы — он преобразует имена в номера. Как и в телефонной системе, важно, чтобы TSAP-адрес сервера имен (или обрабатывающего сервера в протоколе на- чального соединения) был действительно хорошо известен. Если вы не знаете номера телефонной справочной, вы не сможете позвонить оператору. Если вы полагаете, что номер справочной является очевидным, попытайтесь угадать его, находясь в другой стране.