semenov_yu_a_telekommunikacionnye_tehnologii / 1_206
.doc
|
4.2.1.2 SPX-протокол |
||||||||||||||||||||||||||||
|
SPX (Sequence Packet eXchange) и его усовершенствованная модификация SPX II представляют собой транспортные протоколы 7-уровневой модели ISO. Это протокол гарантирует доставку пакета и использует технику скользящего окна (отдаленный аналог протокола TCP). В случае потери или ошибки пакет пересылается повторно, число повторений задается программно. В протоколе SPX не предусмотрена широковещательная или мультикастинг-адресация. В SPX индицируется ситуация, когда партнер неожиданно прерывает соединение, например из-за обрыва связи. Пакеты SPX вкладываются в пакеты IPX. При этом в поле тип пакета IPX записывается код 5. Заголовок пакета SPX всегда содержит 42 байта, включая 30 байт заголовка IPX-пакета, куда он вложен (см. рис. 4.2.1.2.1).
Рис. 4.2.1.2.1. Формат заголовка SPX-пакета Поле управления соединением определяет, является ли данный пакет системным или прикладным. Это поле содержит однобитовые флаги, используемые spx и spx ii для управления потоком данных в виртуальном канале.
Поле тип потока данных характеризует тип данных, помещенных в пакет. Значения этого поля перечислены ниже:
Поля идентификатора отправителя и получателя содержат коды, определяющие участников информационного обмена, присваиваются SPX-драйвером в момент установления связи. В запросах на соединение это поле содержит код 0xffff. Данное поле служит для обеспечения демультиплексирования пакетов, поступающих на один и тот же соединитель (socket). Поле последовательный номер определяет число пакетов пересланных в одном направлении. Каждый из партнеров обмена имеет свой счетчик, который сбрасывается в ноль после достижения 0xffff, после чего счет может продолжаться. Для приложения это поле, также как и последующие два, неприкосновенно. spx-пакеты подтверждения содержат в этом поле порядковый номер последнего посланного пакета. Поле номер подтверждения характеризует последовательный номер следующего пакета, который spx ожидает получить. Любой пакет с порядковым номером меньше, чем задано в поле номера подтверждения, доставлен благополучно и не требует ретрансмиссии. Поле число буферов служит для указания числа доступных на станции буферов (буфера нумеруются, начиная с 0, один буфер способен принять один пакет) и используется для организации управления потоком данных между приложениями. Код этого поля информирует партнера о наибольшем порядковом номере пакета, который может быть послан. Протокол spx посылает пакеты до тех пор, пока локальный последовательный номер не станет равным числу-указателю на удаленной ЭВМ. SPX-протокол не посылает следующий пакет до тех пор, пока не получит подтверждение получения предшествующего. Хотя в протоколе SPX предусмотрен алгоритм скользящих окон (как и в TCP), практически он в настоящее время не используется, что вполне оправдано для локальных сетей. Следует заметить, что для достаточно больших LAN, где пакет проходит через несколько переключателей или маршрутизаторов, пренебрежение техникой окон становится непозволительной роскошью. На случай непредвиденных обрывов связи в spx имеется алгоритм торожевая собакаЭтот алгоритм реализуется специальной программой, которая активируется лишь в случае, когда в течение определенного времени в канале отсутствует трафик в любом из направлений (машина все сделала, а оператор заснул). В этом случае программа посылает специальные пакеты и, если определенное число попыток остучатьсяо партнера не увенчается успехом, сессия прерывается. Если партнер не присылает отклик за оговоренное время (RTT), производится повторная посылка пакета, при этом RTT увеличивается на 50%. Значение RTT не должно превысить величины max_retry_delay, которая по умолчанию равна 5 секундам. Если связь не восстановилась, отправитель пытается найти другой маршрут до адресата. Если маршрут найден, счетчик попыток сбрасывается в ноль и процедура отправки запускается вновь. Допустимое число попыток может лежать в диапазоне 1-255 (по умолчанию - 10). При отсутствии успеха сессия прерывается. Значение RTT определяется по времени отклика ближайшего маршрутизатора, которое удваивается, а к полученной величине добавляется некоторая константа. Для каждой из сессий RTT определяется независимо. Многие временные константы задаются администратором сети. Протокол spx позволяет осуществить от 100 до 2000 соединений одновременно (по умолчанию это число равно 1000). Конфигурационные параметры SPX-протокола (и сети) хранятся в файлах shell.cfg и net.cfg. В 1992 году была разработана новая версия SPX - SPX II. Главное усовершенствование протокола связано с применением пакетов большего размера. Раньше длинные spx-пакеты фрагментировались и пересылались по частям, учитывая, что очередной пакет может быть послан лишь после получения подтверждения, нетрудно понять крайнюю неэффективность такой схемы. Стандарт spx позволяет обмен пакетами с размером, ограниченным только используемой сетевой средой. Так в Ethernet пакет SPX II может иметь длину 1518 байт. Кроме того, SPX II допускает использование технологии окон, то есть можно послать несколько кадров, не дожидаясь получения подтверждения на каждый из уже посланных. Размер окна устанавливается в соответствии с кодом, содержащимся в поле число-указатель (число буферов/пакетов). При необходимости администратор может задать размер окна раз и навсегда. Формат пакетов SPX II несколько отличается от SPX. В SPX II увеличено число допустимых кодов для поля управления соединением, введено дополнительное поле в заголовок подтверждения (два байта, имя поля расширенное подтверждениеНовое поле добавлено после поля число буферов. Алгоритм установление связи в SPX II отличатся от варианта spx тем, что необходимо согласовать размер пересылаемых пакетов.
Рис. 4.2.1.2.2. Формат заголовка SPX-II Управление сетями Novell осуществляется с помощью стандартного протокола SNMP (Simple Network Management Protocol) и управляющей базы данных MIB. |
|
4.2.1.3 Протокол ядра NetWare (NCP) |
||||||||||||||||||
|
NCP представляет собой язык общения серверов и клиентов в среде NetWare. NCP-пакет вкладывается в SPX. Рабочие станции передают свои запросы на запись или чтение файлов, на создание очереди заданий, на поиск в дисковых каталогах и т.д. в виде NCP-сообщений. Прежде чем клиент пошлет NCP-запрос, он должен подключиться к серверу и выдать заявку на формирование NCP-канала связи. Сервер в ответ на этот запрос присылает отклик, в котором содержится подтверждение создания такого канала связи, если запрос удовлетворен. Каждому запросу должен соответствовать отклик. Формат NCP-запроса показан на рис. 4.2.1.3.1.
Рис. 4.2.1.3.1. Формат заголовка пакета NCP Поле тип запроса характеризует запрос, передаваемый от клиента к серверу, возможные значения кодов этого поля приведены ниже (таблица 4.2.1.4). Таблица 4.2.1.3.1 Значения кодов поля тип запроса
Поле номер по порядку используется для отслеживания последовательности связи между клиентом и сервером. Клиент записывает в это поле код, равный номеру по порядку плюс единица. В полях номера канала записан номер, присвоенный клиенту при его регистрации сервером. Поле номер задачи идентифицирует каждую из задач, сделавших запрос. Сервер следит за выполнением задачи и освобождает ресурсы при завершении выполнения. Номер задачи равный нулю говорит серверу, что все задания окончены. Старшая часть номера канала используется лишь при наличии более чем 1000 пользователей, в остальных вариантах это субполе содержит нуль. Сервер в своем отклике сообщает клиенту результаты выполнения его запроса. Отклик, также как и запрос, вкладывается в IPX/SPX-пакет. Формат пакета-отклика показан на рис. 4.2.1.3.2.
Рис. 4.2.1.3.2. Формат заголовка NCP-отклика Поле тип отклика может содержать следующие коды (таблица 4.2.1.3.2): Таблица 4.2.1.3.2 Коды откликов
Сервер отвечает на большую часть запросов, помещая код 3333 в поле типа отклика. Если запрос клиента помещен в очередь, а клиент по таймауту выдал еще один запрос, ему присылается отклик типа апрос обрабатываетсяСтанция клиента при этом сбросит таймер в исходное состояние, добавит 1 к счетчику попыток и продолжит ожидание. По умолчанию запрос можно повторить 20 раз. Поле код завершения указывает на характер завершения выполнения запроса клиента. Код нуль говорит об успешном завершении, любое другое число - об ошибке. Поле состояние канала содержит флаги, характеризующие статус канала, клиенты NetWare должны проверять код этого поля во всех пакетах, приходящих от сервера. Кроме заголовка (запросов и откликов) каждое NCP-сообщение должно содержать в себе код NCP-процедуры, характеризующий запрашиваемую услугу. Часто помимо кода процедуры необходимо указать и ее субкод. Перечень кодов процедур и их функций приведен в приложении. Помимо стандартных пакетов в среде Novell используются несколько вспомогательных видов пакетов. Это пакеты торожевая собакаatchdog), сериализации (serialization) и сообщения. Пакеты торожевая собакаосле IPX-заголовка имеет поля номера канала и сигнатура. Поле номера канала отмечает канал станции, присвоенный ей при регистрации. Поле сигнатура содержит код 0x3F. Если отклика от рабочей станции нет, то сервер передает с интервалом 59 сек 10 аналогичных обачихакетов. Если отклика добиться не удастся, связь со станцией будет разорвана. Период и число таких запросов администратор может изменять в широких пределах. Так как система NetWare продается для каждого сервера отдельно, чтобы контролировать случаи нелегальной загрузки, по сети рассылаются широковещательные пакеты сериализации. Цель такой рассылки - проверка наличия в сети нескольких копий одного и того же программного обеспечения. Пакеты сериализации содержат 36 байт, включая IPX-заголовок, и передаются раз в 66 сек. Эти пакеты помимо IPX-заголовка включают в себя только поле данных (6 байт), где содержится информация о серийном номере программного продукта. Пакеты сериализации всегда посылаются на вход соединителя (socket) с номером 0x0457. При обнаружении нелегальной копии всем пользователям рассылается уведомление yright violationP> Пользователи NetWare могут передавать сообщения рабочим станциям, группам и другим пользователям. Для каждой станции NetWare резервирует буфер для сообщений. Консоль отображает принятое сообщение немедленно, буфер же сохраняет сообщение и может уведомлять о нем пользователя. Для передачи сообщений используется команда SEND. |
|
.2.1.4 Протокол межсетевой передачи больших пакетов (LIP) |
||||||||||||
|
Новый протокол LIP (Large Internet Packet Protocol, 1992 год) разработан Novell для того, чтобы максимально эффективно реализовать возможности, предоставляемые внешними каналами связи. Для повышения производительности операций чтения и записи разработан также протокол пакетного режима (Burst Mode Protocol). Этот протокол позволяет рабочим станциям передавать один запрос на чтение или запись и получать в ответ до 64 Кбайт данных, не посылая дополнительных запросов (используется технология BNETX и VLM). Длина пакета является результатом соглашения между отправителем и получателем, которое достигается в результате диалога. При этом прикладные программы не должны поддерживать пакетный режим (он реализован в оболочке системы). При использовании протокола пакетного режима BNETX клиент и сервер должны быть соответственно подготовлены. На сервере загружается модуль NLM (PBURST.NLM). Согласование размера пакета реализуется путем посылки оболочкой пакетного режима специального запроса на установление соединения с сервером. Это в свою очередь накладывает ограничение на минимальный размер каждого из используемых буферов. Если совершается попытка клиента установить связь в пакетном режиме с сервером, который этот режим не поддерживает, то будет послано сообщение Such Propertyа обмен будет производиться в обычном режиме (NCP-запрос-отклик). Отличие пакетных режимов в BNETX и VLM заключается в управлении скользящим окном. VLM (VLM.EXE), в отличии от BNETX, не устанавливает верхнего предела размера окна. По умолчанию размер окна (число посланных пакетов без подтверждения получения) при чтении равно 16, а при записи - 10. Формат кадров протокола пакетного режима предполагает наличие IPX-заголовка, за которым следует NCP-заголовок пакетного режима. Далее следуют данные. Формат кадра пакетного режима показан на рис. 4.2.1.10. Поле тип запроса NCP-запроса или отклика содержит код 0x7777. Возможные значения флагов перечислены ниже (таблица 4.2.1.6). Таблица 4.2.1.4.1 Значения поля флаги
Рис. 4.2.1.10 Формат кадра пакетного режима В скобках на рисунке указаны размеры полей в байтах. Поле тип потока в данное время может содержать только код 0x02 и означает, что передаются длинные блоки пакетов. Поле идентификатор отправителя является случайным числом и представляет собой уникальный идентификатор канала, работающего в пакетном режиме. Код этого поля формируется отправителем и не должен равняться нулю. Идентификатор канала получателя также случайное число, но задается адресатом и также не должно содержать нуль. Поле номер пакета по порядку служит для отслеживания текущей пакетной операции и увеличивается на единицу для каждого нового пакета. Поле время задержки передачи означает величину задержки между отправкой пакетов и измеряется в сотнях микросекунд. Поле номер блока пакетов идентифицирует принадлежность пакета к конкретному блоку (данные, посылаемые по запросу, образуют один блок). При установлении связи код этого поля делается равным нулю. В дальнейшем при выполнении каждого запроса его значение увеличивается на 1. Поле порядковый номер подтверждения содержит номер блока пакетов, ожидаемый следующим. Поле служит для контроля доставки блоков пакетов. Поле полная длина блока пакетов задает длину блока в байтах и равно сумме длин всех пакетов в блоке. Поле указатель блока пакетов определяет положение конкретного пакета, указатель равный нулю говорит о том, что это первый пакет. Поле длина блока задает длину блока пакетов в октетах. Поле элементы списка фрагментов задает число элементов, пропущенных в процессе реализации пакетной сессии. Если это число равно нулю, пропущенных фрагментов не было. Поле функция определяет разновидность операции (чтение или запись), реализуемой в данной сессии. Последующие поля служат для операций с файлами. |
||||||||||||
|
|
|
.2.1.5 Служба каталогов NetWare (NDS) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
С точки зрения службы каталогов netware (NDS - netware directory services) сеть - это не совокупность ЭВМ, а интегрированная информационная среда. При регистрации в сети клиент получает доступ ко всем ее ресурсам. Для повышения надежности и сокращения времени доступа к сети база данных службы каталогов netware распределена по сети. Отдельные фрагменты базы данных могут располагаться на разных серверах, и могут быть задублированы на нескольких серверах, имеются специальные сетевые средства для синхронизации изменений в этих секциях. Все эти вещи порождают в сети дополнительный трафик, ведь необходимо сравнивать содержимое секций базы данных, их обновление, читать и изменять записи и т.д. Одной из важнейших функций службы каталогов является синхронизация работы ее частей. Синхронизация предполагает определение порядка операций по обслуживанию каталога. В службе каталогов все серверы делятся на:
Существует пять функций NCP, которые поддерживают взаимодействие со службой каталогов Netware. Имеются также функции службы каталогов. Коды функций вставляются в пакеты, посылаемые службой каталогов, и служат в качестве субфункций основных NCP-операций. Таблица (4.2.1.5.1) функций и субфункций службы каталогов представлена ниже. Таблица 4.2.1.5.1 Основные NCP-функции
Запрос nds в режиме ping позволяет запросить сервер о поддержке им операции с кодом 104. Если сервер может выполнить эту операцию, он посылает позитивный отклик, который содержит имя дерева каталога и его глубину. При посылке фрагментированного nds запроса присылается фрагментированный отклик. При обновлении секции каталога netware передает последовательность nds-фрагментов, содержащих изменения данной секции. Формат таких пакетов показан на рис. 4.2.1.5.1. В скобках указаны размеры полей в байтах. Поле максимальный размер фрагмента несет в себе максимальное число байт, которое может быть послано в качестве отклика. Код в этом поле соответствует максимуму, поддерживаемому сетевой средой минус 8 (сумма длин поля длины отклика и поля дескриптора фрагмента). Поле флага фрагмента всегда содержит нуль. Поле внутренняя функция хранит в себе код операции для службы каталогов netware. Таблица команд службы каталогов приведена в приложении (10.5) . В netware имеется развитая собственная система сетевой диагностики, которая позволяет выяснить реальную конфигурацию сети (возможно, что-то не включено или уже сломалось), ее загруженность или частоту ошибок (diagnostic responder). Узлы сети с загруженной программой diagnostic responder должны откликаться на диагностические пакеты, адресованные им или разосланные широковещательно. Наличие отклика говорит о доступности данного сетевого объекта, а его содержимое может нести в себе информацию о конфигурации (наличие IPX/SPX, драйвера локальной сети, программы маршрутизатора или файлового сервера).
Рис. 4.2.1.5.1. Формат пакетов рагментированный NDS-запрос/отклик> Диагностические запросы содержат код 0x0456 в поле соединителя получателя IPX-заголовка. Формат такого запроса показан на рис. 4.2.1.5.2. Однобайтовое поле счетчика исключаемых узлов задает число станций, которые могут не присылать отклик. Нуль в этом поле предполагает, что все станции должны откликнуться. Допустимый диапазон значений кодов в этом поле 0 - 79. При широковещательной рассылке запроса можно сделать так, чтобы сервер и определенные клиенты на запрос не реагировали. Для этого их адреса помещаются в поля адресов исключаемых узлов. Число таких исключений может достигать 80.
Рис. 4.2.1.5.2. Формат диагностического запроса Структура пакета-отклика показана на рис. 4.2.1.5.3. В зависимости от числа компонентов конфигурации пакет-отклик может иметь различную длину. Поля базового и вспомогательного номера версии характеризуют вариант программы diagnostic responder (например, 1.1). Поле номер диагностического соединителя SPX указывает на соединитель, которому отсылаются все диагностические отклики. Поле счетчик компонентов содержит число описаний компонентов, содержащихся в пакете. Поле тип компонента описывает один из компонентов (или процессов) узла, посылающего отклик. Описание компонента может быть простым и расширенным. Простое описание содержит один байт идентификатора компонента. Расширенное описание компонента включает в себя информацию о маршрутизаторах, файл-серверах и невыделенных IPX/SPX. Первое поле в этом случае представляет собой идентификатор расширенного описания, который характеризует тип компонента: Таблица 4.2.1.5.1. Коды типа компонентов
Далее следует поле числа локальных сетей, характеризующее количество сетей, обменивающееся данными с данным компонентом. Для каждой из сетей указывается ее тип, а также адрес сети и узла. Поле типа сети содержит код типа (таблица 4.2.1.5.2). Таблица 4.2.1.5.2 Коды типа сети
Поле адреса сети имеет 4 байта, а поле адреса узла 6 байт, перенаправленные удаленные линии имеют адрес узла 0x00-00-00-00-00-00. Внутренние сети IPX версий 3.x и 4.x имеют адрес узла 0x00-00-00-00-00-01.
Рис. 4.2.1.5.3 Формат пакета диагностического отклика Сервера Novell за счет протоколов RIP и SAP могут заметно загрузить локальную сеть широковещательными сообщениями. По этой причине не следует бездумно множить число таких серверов. |
