соседа информации о модификации таблицы в течение определенного периода
времени.
[ Сеть 8-10 ]
[ Порт 1 ]
[ Порт 2 ]
[ Сеть 2-5 ] . . . [ Сеть 7 ] . . . [ Порт 3 . . . [ Сеть 11 ]
[ Порт 2 ] [ Порт 2 ]
[ Порт 1 ] [Порт 1 ]
[ Сеть 1 ] [ Сеть 6 ] [ Порт 2 ] [ порт 1]
[ Порт 1 ] [ Сеть 12 ]
[ Порт 2 ]
[5] Таблица маршрутизатора R1
[ Номер сети ] [ Расстояние ] [ Порт ] [ Сосед ] [ Состояние ]
[5] Рис. 28-3. Пример таблицы маршрутизации AppleTalk.
[КС 28-10]
[5]В протоколе RTMP специфицированы четыре типа пакетов: данные, запрос,
запрос маршрутных данных и ответ. Пакеты "данные" используются для
транспортировки маршрутной информации. Конечные узлы (не маршрутизаторы) с
помощью "запросов" могут получить номер сети, которой они принадлежат, а
также идентифицировать маршрут, по которому следует передавать пакеты.
Маршрутизатор, получив такой пакет, формирует и передает пакет "ответ".
Конечные узлы, желающие получить пакеты, "данные" имеют возможность
инициировать их передачу с помощью пакета "запрос маршрутных данных". Такой
метод часто применяется в тех случаях, когда для приема маршрутной
информации неодходимо использовать гнездо, отличное от точки, стандартно
используемой в протоколе RTMP. Кроме этого, этот метод применяется в тех
случаях, когда узлам необходимо получить маршрутные данные от
маршрутизатора, который непосредственно не подключен к их сети.
[5]Протокол связывания имен (NBP - Name Binding Protocol)
[5]Идентификаторы узлов (ID) довольно часто меняются. Имена в высокоуровневых
протоколах претерпевают изменения гораздо реже, и, к тому же, они более
просты и удобны для применения в обычной общечеловеческой деятельности. Для
трансляции имен AppleTalk в адреса служит протокол NBP.
В AppleTalk поддерживается концепция Сетевых видимых объектов (NVE - Network
Visible Entity). NVE является адресуемым сетевым набором услуг.
Пользователи и сетевые узлы не являются NVE. Однако адресуемые на сети
процессы, реализующие сетевой сервис, исполняемый на узлах сети, являются
NVE. Гнезда являются примером объектов NVE.
NVE могут иметь множество имен объектов и наборов атрибутов. Имя - это
обычная символьная строка, например, такая David:Mailbox@AnnetteLN,
в то же время, как атрибуты определяют характеристики NVE. Если, к примеру,
NVE соответствует некоторому гнезду, в котором обеспечивается услуга печати,
то атрибуты NVE могут описывать такие характеристики, как тип применяемой
бумаги, вид печатающего механизма и т.д.
Установление соответствия между именем NVE и сетевым адресом осуществляется
с помощью процесса связывания имен. Связывание имен может выполняться при
первом включении пользовательского узла или же непосредственно перед первым
реальным доступом к NVE. Связывание имен выполняется при просмотре таблицы
имен NVE, которая осуществляет отображение имен NVE-объектов на сетевые
адреса. Объединение всех таблиц имен NVE в рамках AppleTalk называется
справочником (directory) имен.
[5]Услуги NVB включают следующее: регистрацию имен, подтверждение наличия
имени, просмотр имен, удаление имен. Услуга регистрации позволяет
зафиксировать отображение имени в сетевой адрес. С помощью услуги
подтверждения наличия имени осуществляется проверка действительности
конкретного отображения имя-адрес. Названия услуг "просмотр имен" и
"удаление имени" говорят сами за себя.
[КС 28-11]
[5]Процесс работы NBP чрезвычайно прост. Приложение, желающее использовать
некоторое имя, обращается для получения сетевого адреса к NBP через услугу
просмотра имен. В результате NBP возвращает соответствующий сетевой адрес.
Приложение может также зарегистрировать новые имена или же удалить имеющиеся,
если это необходимо. Если в процессе регистрации нового имени будет определено
существование такого имени, то в результате будет возвращено сообщение об
ошибке. В случае, когда местный объект NBP не может обнаружить запрашиваемое
имя в своей таблице, подготавливается запрос "обзор имен" для передачи его
всем узлам локальной сети. Передача пакета осуществляется в соответствии с
протоколом DDP.
Протокол DDP не поддерживает межсетевую операцию широкого вещания, поэтому
рассылка пакетов "обзор имен" не может быть выполнена для всей интерсети.
Однако все же из-за существования необходимости просмотра имен в рамках групп
логически связанных узлов в AppleTalk было введено понятие "зоны".
Зона в AppleTalk представляет собой логически связанную группу, состоящую
из узлов AppleTalk. Зона может охватывать множество сетей, но вовсе
необязательно, чтобы все узлы одного сетевого сегмента принадлежали одной
и той же зоне. Специфические узлы в то же время могут принадлежать только
одной зоне. Зона приписки узла выбирается из списка зон при включении узла
в данную сеть. Все узлы нерасширяемой сети должны принадлежать одной зоны.
Выполнение операции просмотра имен в рамках зоны осуществляется в
соответствии с протоколом NBP следующим образом. Запрос на просмотр к NBP
передается в локальный маршрутизатор. Маршрутизатор, в свою очередь,
выполняет широковещательную передачу запроса во все сети, которые имеют узлы,
принадлежащие целевой зоне. Выполнение этой процедуры осуществляется согласно
информационному протоколу зон (ZIP - Zone Information Protocol).
[КС 28-12]
[5]Информационный протокол зон (ZIP).
[5]Протокол ZIP обеспечивает поддержку отображения "номер сети - имя зоны"
с помощью таблиц ZIT (Zone Information Table). В основном протокол ZIP
применяется маршрутизаторами, хранящими таблицы ZIT. Конечные узлы применяют
протокол ZIP исключительно для выбора зоны или получения межсетевой
информации о зонах. Это выполняется в процессе их запуска (startup).
[Номер сети ] [ Имена зон ]
[5] Рис. 28-4. Информационная таблица зон (ZIT) AppleTalk
[5]Все сети Appletalk имеют соответствующий список зон. В протоколе NBP этот
список используется для определения того, в какие сети необходимо делать
передачу широковещательного запроса имени. Конечные узлы сети применяют
список зон для выбора имени зоны в ходе процедур инициализации (startup).
Запросы протоколы ZIP позволяют получить списки зон, соответствующих одной
или нескольким сетям. В протоколе ZIP поддерживаются и другие типы запросов.
Существует запрос для получения списка имен зон по всей интерсети AppleTalk.
Эта процедура полезна в случаях, когда необходимо выполнить широковещательный
опрос интерсети. Другой запрос используется для получения имени зоны, которой
принадлежит узел-инициатор.
[КС 28-13]
[ AppleTalk и ]
[ Транспортный уровень ]
[ Прикладной ]
[ Представительный ]
[ Сеансовый ]
[ Транспортный ]
[ Сетевой ]
[ Канальный ]
[ Физический ]
[ к рис. на стр. 28-14 ( в поле рисунка) ]
[1]Протокол транспортного уровня
[5]Как и в других сетевых архитектурах в рамках AppleTalk предусматривается
надежный транспортный механизм. Механизм обеспечивается протоколом транзакций
AppleTalk (ATP - AppleTalk Transaction Protocol).
[5]Протокол транзакций AppleTalk (ATP)
[5]В протоколе ATP выполняется подтверждение доставки информации, а также
повторная передача данных в случае, когда они остаются неподтвержденными в
течение заданного периода времени. В отличие от большинства транспортных
протоколов ATP основывается на концепции транзакции, а не на простой передаче
потока данных по надежному соединению.
Транзакция представляет собой композицию из запроса рабочей станции, за
которым следует ответ сервера. Запрос и ответ одной транзакции обеспечиваются
уникальным идентификатором транзакции. Транзакции выполняются между двумя
гнездами (sockets), т.е. двумя высокоуровневыми процессами.
[КС 28-14]
[5]В протоколе ATP различаются два типа транзакций "строго одноразовые"
(ХО - exactly once) и "по-крайней мере одноразовые" ALO (at least once).
ХО - транзакции требуются в тех ситуациях, когда повторное исполнение
транзакции может привести к серьезным последствиям. Такие ситуации называются
"щекотливыми" (non-idempotent). Примером щекотливой ситуации является то, что
может произойти с транзакцией Банкомата (ATM). Дублирование перечисления
десяти миллионов долларов с одного счета на другой может привести к
разрушительным результатам. ALO - транзакции являются приемлемыми в более
устойчивых (idempotent) ситуациях.
Подобно протоколу TCP (глава 23) и другим популярным протоколам в протоколе
ATP предусмотрены операции фрагментации и сборки сообщений. Операции
фрагментации/сборки исполняются в тех случаях, когда характеристики канала
передачи данных не позволяют передавать слишком длинные сообщения. В протоколе
ATP существует ограничение на длину сообщения, количество фрагментов (пакетов)
в сообщении не должно быть более 8. Каждый пакет не должен быть больше 578
байтов.
В заголовках ATP пакетов с помощью битовой шкалы фиксируются потерянные или
принятые не в требуемой последовательности фрагменты. Если ATP пакет является
требованием транзакции, то в этом поле заголовка размещается, так называемая,
шкала транзакции. Если же пакет содержит ответ транзакции, то в
рассматриваемом поле заголовка передается последовательный номер ATP пакета.
В случае, когда поле "шкала/номер" выступает в роли битовой шкалы , то в нем
указывается число буферов (от 0 до 7), которым располагает инициатор
требования для приема ответов партнера. Если же поле выступает в роли
"номера", то в нем размещается последовательный номер (от 0 до 7)
соответствующего передаваемого фрагмента (ответа). Поскольку входящие пакеты
отмечены ожидаемыми последовательными номерами, то инициатор транзакции
(требования) имеет возможность фиксировать любое нарушение последовательности