Формат диагностического запроса
Рисунок 4.2.1.5.2. Формат диагностического запроса
Структура пакета-отклика показана на Рисунок 4.2.1.5.3. В зависимости от числа компонентов конфигурации пакет-отклик может иметь различную длину. Поля базового и вспомогательного номера версии характеризуют вариант программы diagnostic responder (например, 1.1). Поле номер диагностического соединителя SPX указывает на соединитель, которому отсылаются все диагностические отклики. Поле счетчик компонентов содержит число описаний компонентов, содержащихся в пакете. Поле тип компонента описывает один из компонентов (или процессов) узла, посылающего отклик. Описание компонента может быть простым и расширенным. Простое описание содержит один байт идентификатора компонента. Расширенное описание компонента включает в себя информацию о маршрутизаторах, файл-серверах и невыделенных IPX/SPX. Первое поле в этом случае представляет собой идентификатор расширенного описания, который характеризует тип компонента:
Формат кадра NBFCP
Рисунок 4.2.3.1. Формат кадра NBFCP
Поле тип содержит код 2, поле длина определяет размер заголовка, если длина=8, имя партнера отсутствует. Поле класс партнера идентифицирует тип системы отправителя (см. таблицу 4.2.3.1).
Формат отклика WINS
Рисунок 4.2.3.2. Формат отклика WINS
Поле флаги имеет следующую структуру:
|
0 _ _ _ |
_ _ _ _ |
Команда |
|
_ 000 |
0 _ _ _ |
Запрос |
|
_ _ _ _ |
_ _ 0 _ |
Не укорочено |
|
_ _ _ _ |
_ _ _ 0 |
Рекурсия нежелательна |
|
_ _ _ _ |
_ _ _ 0 |
Рекурсия нежелательна |
|
1_ _ _ |
_ _ _ _ |
Отклик |
|
_ 000 |
0 _ _ _ |
Запрос |
|
_ _ _ _ |
_ _ 0 _ |
Не укорочено |
|
_ _ _ _ |
_ 1 _ _ |
Официальный ответ |
Для поля флаги имени характерна следующая структура
|
0_ _ _ |
_ _ _ _ |
Уникальное имя NetBIOS |
|
_ 10 _ |
_ _ _ _ |
Узел М-типа |
|
_ _ _ _ |
_ 1 _ _ _ |
Активное имя |
|
_ _ _ _ |
_ _ 0_ |
Временное имя |
Для поля флагов имени группы характерно следующее назначение бит
|
1 _ _ _ |
_ _ _ _ |
Имя группы NetBIOS |
|
_ 10 _ |
_ _ _ _ |
Узел М-типа |
|
_ _ _ _ |
_ 1 _ _ _ |
Активное имя |
|
_ _ _ _ |
_ _ 0_ |
Временное имя |
Протокол WINS весьма удобен для сбора данных о МАС-адресах ЭВМ в многоранговой сети, где получить эти данные с помощью ARP-запросов невозможно. Какие-то данные можно извлечь из кэша маршрутизаторов или таблиц сетевых переключателей, если они доступны с помощью SNMP-запросов. Но WINS может дать больше данных, если рабочая станция использует операционную систему Windows. Так что, когда, скажем, программа Black ICE Defender пришлет вам MAC-адрес атакера, сидящего на другом континенте, не удивляйтесь, на помощь был призван протокол WINS.
Формат пакета диагностического отклика
Рисунок 4.2.1.5.3 Формат пакета диагностического отклика
Сервера Novell за счет протоколов RIP и SAP могут заметно загрузить локальную сеть широковещательными сообщениями. По этой причине не следует бездумно множить число таких серверов.
Формат пакетов “Фрагментированный NDS-запрос/отклик”
Рисунок 4.2.1.5.1. Формат пакетов “Фрагментированный NDS-запрос/отклик”
Диагностические запросы содержат код 0x0456 в поле соединителя получателя IPX-заголовка. Формат такого запроса показан на Рисунок 4.2.1.5.2. Однобайтовое поле счетчика исключаемых узлов задает число станций, которые могут не присылать отклик. Нуль в этом поле предполагает, что все станции должны откликнуться. Допустимый диапазон значений кодов в этом поле 0 - 79. При широковещательной рассылке запроса можно сделать так, чтобы сервер и определенные клиенты на запрос не реагировали. Для этого их адреса помещаются в поля адресов исключаемых узлов. Число таких исключений может достигать 80.
Формат сообщения NTP
Рисунок 4.4.15.1. Формат сообщения NTP.
Номер версии (VN) - трехбитовое поле, указывающее на номер версии протокола NTP, в настоящее время (3).
Режим (Mode) - трехбитовое поле, определяющее режим, значения кодов режима приведены в таблице 4.4.15.2.
Слой (Stratum) - 8-битовое поле, определяющее код слоя, где работают локальные часы. Коды слоя представлены в таблице 4.4.15.3. Возможные значения кодов лежат в интервале от нуля до NTP.INFIN включительно.
Период запросов (poll interval) - 8-битовое поле, указывающее на максимальное значение интервала между запросами. Код, записанный в этом поле, интерпретируется как целое число со знаком и характеризует значение периода в секундах, как ближайшее к величине степени двух. Коды, которые могут быть записаны в этом поле, должны лежать в интервале между NTP.MAXPOLL и NTP.MAXPOLL включительно.
Точность (precision) - 8-битовое поле, обозначающее точность локальных часов в секундах. Код поля интерпретируется как целая степень со знаком числа 2.
Базовая задержка (Root Delay) - 32-битовое поле, характеризующее RTT до эталонного источника в секундах. Код поля интерпретируется как число с фиксированной запятой, размещенной между битами 15 и 16. Заметим, что величина этого кода может иметь и отрицательное значение (зависит от точности часов и величины дрейфа).
Базовая дисперсия (Root Dispersion) - 32-битовое поле, определяющее максимальную ошибку по отношению к эталонному источнику в секундах. Код поля интерпретируется как число с фиксированной запятой (между 15 и 16 битами). Допустимы только положительные значения.
Идентификатор эталонных часов (Reference Clock Identifier) - 32-битовое поле, идентифицирующее конкретные эталонные часы. В случае кода слоя нуль (не специфицировано) или слоя 1 (первичный эталон), это 4-октетная комбинация выравнивается по левому краю и дополняется нулями (ASCII). Когда идентификатор в NTP не специфицирован, предлагаются ascii- идентификаторы, приведенные в таблице 4.4.15.4.
В случае слоя 2 и больше (вторичный эталон) - это 4-октетный IP-адрес ЭВМ - первичного эталона.
Эталонная временная метка (Reference Timestamp) - поле локального времени (64-битовый формат временных меток), когда часы корректировались в последний раз.
Исходная временная метка (Originate Timestamp) определяет время, когда запрос направлен серверу (стандартный 64-битовый формат временных меток).
Получаемая временная метка (Receive Timestamp) - время, когда запрос прибыл к серверу (стандартный 64-битовый формат временных меток).
Передаваемая временная метка (Transmit Timestamp) - локальное время, когда послан отклик сервером (стандартный 64-битовый формат временных меток).
Аутентификатор (authenticator) (опционно) - поле, содержащее аутентификационную информацию. Используется лишь в случае реализации NTP-аутентификации.
Приложение Б. Сообщения управления NTP
В сетевой среде должны быть средства управления программами NTP, такие как установка индикатора добавления секунды (Leap-Indicator) со стороны первичного сервера, настройка различных системных параметров и процедур мониторинга. Такие операции могут быть реализованы с привлечением протокола snmp и соответствующего расширения базы данных MIB. Однако в тех случаях, когда такие средства недоступны, эти функции могут быть реализованы с помощью специальных управляющих NTP-сообщений.
Управляющие сообщения NTP имеют код 6 в поле режима первого октета NTP-заголовка. Формат поля данных специфичен для каждой из команд или отклика. Однако, в большинстве случаев формат конструируется так, чтобы облегчить его непосредственное чтение. Как правило, он состоит из ASCII-строк. Если используется аутентификатор, поле данных дополняется нулями до границы, кратной целому числу 32-битных слов.
IP-ЭВМ не должны обрабатывать дейтограммы длиннее 576 октетов; однако, некоторые команды или отклики могут содержать данные, непомещающиеся в одну дейтограмму. Для решения данной проблемы все октеты сообщения нумеруются, начиная с нуля. При передаче фрагментов сообщения номер первого октета записывается в поле смещения (offset), а число октетов в поле длины.
Бит (M - more) устанавливается во всех фрагментах за исключением последнего.
Большинство контрольных функций включает посылку команды и получение отклика. Отправитель выбирает ненулевой порядковый номер и устанавливает статусное поле и биты R и E равными нулю. Получатель интерпретирует код операции и дополнительную информацию, содержащуюся в поле данных, вносит изменение в поле статуса и устанавливает бит R=1, а также возвращает три 32-битного слова заголовка вместе с другой дополнительной информацией поля данных. В случае неверного формата сообщения или ошибки в поле данных получатель заносит соответствующий код в поле статуса, устанавливает биты R и E равными 1, и опционно записывает диагностическое сообщение в поле данных.
Некоторые команды осуществляют чтение или запись для системных переменных и переменных партнеров для ассоциации, идентифицированной в команде. Другие читают или записывают значения переменных, связанных с радио-часами и другими приборами, имеющими непосредственное отношение к эталонам времени. Для определения ассоциации используется ее 16-битовый идентификатор. Для системных переменных используется идентификатор нуль. Управляющий объект может затребовать текущий список идентификаторов с тем, чтобы их использовать в дальнейшем. При попытке употребить уже недействительный идентификатор будет прислан соответствующий отклик, после чего необходимо запросить список идентификаторов еще раз.
Некоторые события, такие как изменение статуса доступа к партнеру, не сопряжены с какими-либо командами и происходят асинхронно. Программа может запоминать информацию о таких событиях и пересылать ее в откликах. Текущий статус и краткая аннотация чрезвычайных событий пересылаются каждым откликом. Биты в статусном поле указывают на то, произошло ли какое-либо событие с момента предыдущего отклика и было ли их больше одного.
Формат сообщений управления NTP
Формат заголовков управляющих NTP-сообщений показан на Рисунок 4.4.15.2. Этот заголовок располагается непосредственно вслед за UDP-заголовком.
Формат управляющего сообщения ntp
Рисунок 4.4.15.2. Формат управляющего сообщения ntp
Первые два бита, обозначенные ZZ, должны всегда содержать 0.
Номер версии (VN - version number) - трехбитовое поле, указывающее на номер версии протокола NTP, в настоящее время (3).
Режим (Mode) - трехбитовое поле, определяющее режим, значение кода режима для управляющих сообщений равно 6.
Бит отклика (R) - равен нулю для команд и 1 для откликов.
Бит ошибки (E) - равен нулю для нормального отклика и 1 в случае ошибки.
Бит продолжения (M - more) - равен нулю для последнего фрагмента и 1 - для всех остальных.
Код операции (OP) - 5-битовое поле, определяющее код команды. Значения кодов и их функции представлены в таблице 4.4.15.5.
Формат заголовка NCP-отклика
Рисунок 4.2.1.3.2. Формат заголовка NCP-отклика
Поле тип отклика может содержать следующие коды (таблица 4.2.1.3.2):
Формат заголовка пакета NCP
Рисунок 4.2.1.3.1. Формат заголовка пакета NCP
Поле тип запроса характеризует запрос, передаваемый от клиента к серверу, возможные значения кодов этого поля приведены ниже (таблица 4.2.1.4).
Формат запроса WINS
Рисунок 4.2.3.2. Формат запроса WINS
В поле данных UDP-дейтограммы отклика располагается 2-байтовое поле идентификатора, аналогичного содержащемуся в пакете запроса. Далее следует поле флагов с длиной в два октета. Формат поля данных UDP-дейтограммы отклика показан на Рисунок 2.
Форматы статусных слов
Рисунок 4.4.15.3. Форматы статусных слов
Статус партнера - 5-битный код, характеризующий состояние партнера, определяемого процедурой обмена. Значения этого поля представлены в таблице 4.4.15.8.
Маршрутизатор с мя входными каналами
Рисунок 4.8. Маршрутизатор с 4-мя входными каналами, в каждом из которых ждет очереди передачи по одному пакету. В правой части рисунка представлен порядок посылки этих пакетов.
Пакеты на рисунке имеют от трех до девяти октетов. Порядок пересылки октетов показан в левой части рисунка. В отсутствии поступления новых пакетов, кадры, записанные в буфер будут переданы в порядке, представленном в правой части рисунка. Особенностью этого алгоритма является равенство приоритета всех входных каналов.
При передаче данных на большие расстояния с большими значениями RTT эффективность использования метода блокирующих пакетов снижается. Пока блокирующий пакет дойдет через ряд промежуточных узлов до отправителя, на вход получателя поступит большое число пакетов, которые не только усугубят ситуацию перегрузки, но и могут вызвать потерю какой-то их доли, что, в свою очередь, может потребовать повторной пересылки следовавших за ними кадров. Для повышения эффективности часто применяется схема, при которой блокирующие пакеты воздействуют на все маршрутизаторы по пути своего следования. В этом случае снижения потока можно ожидать уже чарез время, равное RTT до узла, ближайшего к получателю пакетов. Такая схема требует того, чтобы все промежуточные узлы имели достаточно емкие буферы, в противном случае возможны потери.
В протоколе TCP используется алгоритм управления трафиком, называемый "скользящее окно". Здесь размер окна, которое определяет число сегментов, посылаемых без получения подтверждения, варьируется в зависимости от наличия потерь пакетов. При большой вероятности потери система переходит в режим, когда очередной пакет не посылается до тех пор, пока не будет подтверждено получение предшествующего. При серьезных перегрузках, когда потери становятся значительными, нарушается механизм вычисления значений RTT и таймаутов, что может приводить к трудно предсказуемым последствиям. Следует обратить внимание, что в протоколе UDP какого-либо механизма управления трафиком не предусмотрено. По этой причине для некоторых мультимедийных задач, следует предусматривать другие, например, ICMP-способы подавления перегрузки. В приложениях типа NFS, где используется UDP, для подавления перегрузки используется упомянутый выше ICMP-механизм. К сожаления в ряде мультимедийных приложений потеря пакетов не контролируется (например IP-телефония). Там шлюз 100-10Мбит/с может восприниматься как канал с вероятностью потери пакета 90%.
Если другие способы испробованы, а перегрузка не исчезла, маршрутизатор начинает отбрасывать приходящие пакеты, которые уже не может обработать. Самое простое - это предоставить случаю выбор отбрасываемых пакетов. Но это не лучшая тактика. В случае пересылки мультимедийных данных предпочтение следует делать для последних полученных пакетов, а "старые" пакеты выбрасывать. При передаче файлов наоборот "старый" пакет имеет приоритет, ведь если его отбросить, придется повторно передавать не только его, но и все последующие пакеты. Некоторые методы передачи изображения требуют передачи время от времени всего кадра с последующей пересылкой только фрагментов, где произошли изменения. В таких условиях потеря пакета, составляющего базовый кадр, менее желательна. Сходные обстоятельства могут возникать и в других приложениях. Можно помечать пакеты, присваивая им определенные уровни приоритетов, что позволит осознанно принимать решение об отбрасывании того или иного пакета в условиях перегрузки. В перспективе проблема может быть решена на чисто коммерческой основе - компонента трафика, помеченная как высоко приоритетная, будет оплачиваться по более высокому тарифу. В некоторых сетях определенное количество пакетов объединяется в группы, образующие сообщение. Если одна ячейка такого сообщения выбрашена, все сообщение будет повторно переслано (смотри, например, адаптационные уровни сетей ATM).
Некоторые топологии вычислительных систем
Рисунок 4.3. Некоторые топологии вычислительных систем
Метод доступа к сети
Метод доступа определяет метод, который используется при мультиплексировании/демультиплексировании данных в процессе передачи их по сети. Большая часть современных сетей базируется на алгоритме доступа CSMA/CD (carrier sensitive multiple access with collision detection), где все узлы имеют равные возможности доступа к сетевой среде, а при одновременной попытке фиксируется столкновение и сеанс передачи повторяется позднее. Здесь нет возможности приоритетного доступа и по этой причине такие сети плохо приспособлены для задач управления в реальном масштабе времени. Некоторое видоизменение алгоритма CSMA/CD (как это сделано в сетях CAN или в IBM DSDB) позволяют преодолеть эти ограничения. Доступ по схеме CSMA/CD (из-за столкновений) предполагает ограничение на минимальную длину пакета. По существу, метод доступа CSMA/CD предполагает широковещательную передачу пакетов (не путать с широковещательной адресацией). Все рабочие станции логического сетевого сегмента воспринимают эти пакеты хотя бы частично, чтобы прочесть адресную часть. При широковещательной адресации пакеты не только считываются целиком в буфер, но и производится прерывание процессора для обработки факта прихода такого пакета. Логика поведения субъектов в сети с доступом CSMA/CD может варьироваться. Здесь существенную роль играет то, синхронизовано ли время доступа у этих субъектов. В случае Ethernet такой синхронизации нет. В общем случае при наличии синхронизации возможны следующие алгоритмы.
А.
Если канал свободен, терминал передает пакет с вероятностью 1.
Если канал занят, терминал ждет его освобождения, после чего производится передача.
Б.
Если канал свободен, терминал передает пакет.
Если канал занят, терминал определяет время следующей попытки передачи. Время этой задержки может задаваться некоторым статистическим распределением.
В.
Если канал свободен, терминал с вероятностью р передает пакет, а с вероятностью 1-р он откладывает передачу на t секунд (например, на следующий временной домен).
При повторении попытки при свободном канале алгоритм не изменяется.
Если канал занят, терминал ждет пока канал не освободится, после чего действует снова согласно алгоритму пункта 1.
Алгоритм А на первый взгляд представляется привлекательным, но в нем заложена возможность столкновений с вероятностью 100%. Алгоритмы Б и В более устойчивы в отношении этой проблемы.
Следующим по популярности после csma/cd является маркерный доступ (Token Ring, Arcnet и FDDI), который более гибок и обеспечивает приоритетную иерархию обслуживания. Массовому его внедрению препятствует сложность и дороговизна. Хотя региональные сети имеют самую разнообразную топологию, практически всегда они строятся на связях точка-точка.
В таблице 4.1 представлены сводные данные по основным видам локальных сетей, используемых в настоящее время (список не является полным).
NetBIOS
4.2.3 NetBIOS
Протокол NetBIOS был создан для работы в локальных сетях. Система NetBIOS предназначена для персональных ЭВМ типа IBM/PC в качестве интерфейса, независящего от фирмы-производителя. NetBIOS использует в качестве транспортных протоколов TCP и UDP. Описание NetBIOS содержится в документе IBM 6322916 "Technical Reference PC Network" (см. также RFC-1001-2, -1088 и STD-48).
ftp://ietf.org/internet-drafts/draft-ietf-pppext-netbios-fcp-08.txt) создан для использования группой ЭВМ, поддерживает как режим сессий (работа через соединение), так и режим дейтограмм (без установления соединения). 16-и символьные имена объектов в netbios распределяются динамически. netbios имеет собственную dns, которая может взаимодействовать с интернетовской. Имя объекта при работе с NETBIOS не может начинаться с символа *.
Приложения могут через netbios найти нужные им ресурсы, установить связь и послать или получить информацию. NETBIOS использует для службы имен порт - 137, для службы дейтограмм - порт 138, а для сессий - порт 139.
Любая сессия начинается с netbios-запроса, задания ip-адреса и определения tcp-порта удаленного объекта, далее следует обмен NETBIOS-сообщениями, после чего сессия закрывается. Сессия осуществляет обмен информацией между двумя netbios-приложениями. Длина сообщения лежит в пределах от 0 до 131071 байт. Допустимо одновременное осуществление нескольких сессий между двумя объектами.
При организации IP-транспорта через NETBIOS IP-дейтограмма вкладывается в NETBIOS-пакет. Информационный обмен происходит в этом случае без установления связи между объектами. Имена Netbios должны содержать в себе IP-адреса. Так часть NETBIOS-адреса может иметь вид, ip.**.**.**.**, где IP указывает на тип операции (IP через Netbios), а **.**.**.** - ip-адрес. Система netbios имеет собственную систему команд (call, listen, hang up, send, receive, session status, reset, cancel, adapter status, unlink, remote program load) и примитивов для работы с дейтограммами (send datagram, send broadcast datagram, receive datagram, receive broadcast datagram).
Все оконечные узлы netbios делятся на три типа:
Широковещательные ("b") узлы;
узлы точка-точка ("p");
узлы смешанного типа ("m").
IP-адрес может ассоциироваться с одним из указанных типов. B-узлы устанавливают связь со своим партнером посредством широковещательных запросов. P- и M-узлы для этой цели используют netbios сервер имен (NBNS) и сервер распределения дейтограмм (NBDD).
В настоящее время (1985 г) разработана улучшенная версия протокола NETBIOS - NetBeui (NetBios extended user interface). Этот новый протокол используется операционными системами LAN manager, LAN server, Windows for Workgroups и Windows NT, а по своей функции занимает нишу протоколов TCP/IP, охватывая связной, сетевой и транспортный уровни. Здесь стандартизован формат пакетов NetBios, добавлены некоторые новые функции. netbuei базируется на протоколе OSI LLC2, вводит стандарт на формат кадра netbios (NDF) и использует NetBios в качестве интерфейса высокого уровня. Протокол обладает высоким быстродействием и служит для объединения небольших локальных сетей (20-200 ЭВМ) друг с другом или с главной ЭВМ. Этот протокол соответствует связному, сетевому и транспортному уровню модели OSI. В новых версиях NetBuei (3.0 и выше) снято ограничение на число одновременных сессий (254). Среди ограничений NetBuei следует назвать отсутствие внутренней маршрутизации и серьезные ограничения при работе в региональных сетях. По этой причине netbuei рекомендуется для локальных сетей (здесь они предпочтительнее других протоколов), а для внешних связей использовать, например, TCP/IP.
Для подключения терминальной системы к локальной сети или к другой терминальной системе разработан протокол NBFCP (NetBios frames control protocol, код поля протокола = 803F), который в свою очередь базируется на протоколе PPP.
Формат кадра протокола NBFCP показан на Рисунок 4.2.3.1.
Г Временная шкала NTP и ее хронометрия
Приложение Г. Временная шкала NTP и ее хронометрия
Ниже рассматривается соответствие временной шкалы NTP и UTC (Coordinated Universal Time). Синхронизация часов предполагает их согласование по частоте и времени.
Для синхронизации необходимо уметь сравнить их частоты и показания. Базовыми источниками временных стандартов традиционно являлись периоды движения Земли, Луны и других космических объектов. К сожалению, они не слишком стабильны.
Первичная частота и стандарты времени
Первичными стандартами частоты являются осцилляторы с высокой стабильностью. Такие стандарты используют межуровневые переходы в атомах водорода, цезия и рубидия. В таблице 4.4.15.12 приведены характеристики типичных стандартов времени. Локальные же часы обычно используют некомпенсированные кварцевые генераторы. Такие генераторы не только подвержены дрейфам под действием изменения параметров окружающей среды, но систематически меняют свои свойства со временем (старение).
Даже если кварцевый генератор имеет температурную компенсацию, его частота должна время от времени сравниваться первичным стандартом для обеспечения высокой точности.
Обычно часовые осцилляторы классифицируются по трем параметрам: стабильность, разброс и блуждание. Стабильность определяется систематическими вариациями частоты со временем. Синонимом нестабильности является старение и дрейф. Разброс (называемый также временным дрожанием) характеризует кратковременные случайные вариации частоты с составляющими более 10 Гц, в то время как блуждание характеризует медленные вариации частоты с составляющими менее 10 Гц.
В Аутентификация
Приложение В. Аутентификация
Требования надежности NTP подобны аналогичным для других протоколов, работающих с большим числом партнеров и служащих для маршрутизации, управления и доступа к файлам. Система должна противостоять случайным ошибкам и злонамеренным действиям.
Механизм управления доступом в NTP отвечает всем базовым требованиям. Различные проверки препятствуют большинству возможных атак, связанных с подменой временных меток.
Однако имеется возможность того, что хакер нарушит процедуру синхронизации путем модификации NTP-сообщений. Для подавления такой возможности нужно привлекать криптографические механизмы аутентификации (в частности сертификаты).
Механизм, который работает на прикладном уровне, служит для того, чтобы исключить неавторизованную модификацию потока сообщений. Это достигается с помощью контрольных крипто-сумм, вычисляемых отправителем и проверяемых получателем. Однако сам протокол NTP не имеет средств для работы с сертификатами и ключами.
Процедура вычисления контрольной крипто-суммы использует алгоритм DES (Data Encryption Standard) [NBS77].
Механизм аутентификации NTP
Когда предполагается использовать аутентификацию, инициализируется ряд переменных, определяющих выбор сертификата, алгоритма шифрования и крипто-ключ и, возможно, другие параметры. Процедуры инициализации и выбора этих переменных не регламентируются протоколом NTP. Набор переменных партнера и пакетов может включать в себя следующие компоненты:
Бит разрешения аутентификации (peer.authenable). Этот бит указывает, что ассоциация работает в режиме аутентификации. Для сконфигурированных партнеров этот бит определяется на фазе инициализации. Для неконфигурированных - этот бит делается равным 1, если приходящее сообщение содержит аутентификатор, в противном случае =0.
Бит аутентификации (peer.authentic). Этот бит указывает, что последнее сообщение, полученное от партнера, было корректно аутентифицировано.
Идентификатор ключа (peer.hostkeyid, peer.peerkeyid, pkt.keyid). Это целое число идентифицирует криптографический ключ, используемый для генерации кода аутентификации сообщения.
Системная переменная peer. hostkeyid используется для активной ассоциации. Переменная peer.peerkeyid инициализируется нулем, когда ассоциация сформирована.
Криптографические ключи (sys.key). Это набор 64-битовых ключей DES, где 7 младших бит каждого октета соответствуют битам 1-7 DES, а старший бит соответствует биту четности 8 (сумма нечетна).
Контрольная крипто-сумма (pkt.check). Крипто-сумма вычисляется процедурой шифрования.
Поле аутентификатора состоит из двух субполей, одно содержит переменную pkt.keyid, а другое переменную pkt.check, вычисленную программой шифрования, вызываемой процедурой передачи протокола NTP, а также программой дешифровки, которая вызывается процедурой приема NTP. Ее присутствия определяется по общей длине UDP-дейтограммы. Для целей аутентификации NTP-сообщение дополняется нулями, для того чтобы сделать ее длину кратной 64 битам. Аутентификатор содержит 96 бит, куда входят 32-битовый идентификатор ключа и 64-битовая крипто-сумма. Дополнительная информация (например, о сертификате и алгоритме шифрования), если необходимо, может быть вставлена между NTP-сообщением и идентификатором ключа. Подобно аутентификатору эта информация не включается в контрольное крипто-суммирование.
Процедуры аутентификации NTP
Когда используется аутентификация для реализации протокола NTP, привлекается две дополнительные процедуры. Одна из них формирует крипто-сумму для передаваемых сообщений, а другая дешифрует и проверяет корректность контрольной суммы получаемых сообщений. Процедуры представляют собой варианты программ, используемых для реализации алгоритма DES и описанных в [NBS80]. На самом деле процедура не связана жестко с алгоритмом DES, а лишь предполагают работу с 64-битовыми блоками данных.
Примеры сетевых топологий
Рисунок 4.1. Примеры сетевых топологий
К первым трем типам топологии относятся 99% всех локальных сетей. Наиболее популярный тип сети – Ethernet, может строиться по схемам 1 и 2. Вариант 1 наиболее дешев, так как требует по одному интерфейсу на машину и не нуждается в каком-либо дополнительном оборудовании. Сети Token Ring и FDDI используют кольцевую топологию (3 на Рисунок 4.1), где каждый узел должен иметь два сетевых интерфейса. Эта топология удобна для оптоволоконных каналов, где сигнал может передаваться только в одном направлении (но при наличии двух колец, как в FDDI, возможна и двунаправленная передача). Нетрудно видеть, что кольцевая топология строится из последовательности соединений точка-точка.
Используется и немалое количество других топологий, которые являются комбинациями уже названных. Примеры таких топологий представлены на Рисунок 4.2.
Вариант А на Рисунок 4.2 представляет собой схему с полным набором связей (все узлы соединены со всеми), такая схема используется только в случае, когда необходимо обеспечить высокую надежность соединений. Эта версия требует для каждого из узлов наличия n-1 интерфейсов при полном числе узлов n. Вариант Б является примером нерегулярной топологии, а вариант В – иерархический случай связи (древовидная топология).
Если топологии на Рисунок 4.1 чаще применимы для локальных сетей, то топологии на Рисунок 4.2 более типичны для региональных и глобальных сетей. Выбор топологии локальной или региональной сети существенно сказывается на ее стоимости и рабочих характеристиках. При этом важной характеристикой при однородной сети является среднее число шагов между узлами d.
Протокол аутентификации Нидхэма-Шредера в случаях симметричной и асимметричной системы шифрования
6.4.10 Протокол аутентификации Нидхэма-Шредера в случаях симметричной и асимметричной системы шифрования
Протокол Нидхэма-Шрёдера предназначен для решения проблемы аутентификации (см., например, http://www.cs.sunysb.edu/~zhaoming/np.html,
http://dimacs.rutgers.edu/Workshops/Security/program2/boyd/node14.html, а также [1]). Протоколу уже более 20 лет. Алгоритм предназначен для организации аутентифицированного канала между разными ЭВМ в сети по схеме точка-точка. Задача решается с помощью одного или двух серверов аутентификации с использованием общедоступных или общих секретных ключей. Данный протокол предоставляет децентрализованную услугу аутентификации.
Операция аутентификации может охватывать несколько процессов.
Установление виртуального канала двунаправленного обмена сообщениями между двумя субъектами, работающими на разных ЭВМ.
Установление однонаправленного обмена, который, например, имеет место при отправке почты. Здесь ситуация осложняется тем, что субъекты могут не быть одновременно доступны через сеть и не могут непосредственно обмениваться сообщениями.
Коммуникация, при которой источник информации и ее целостность может гарантироваться третей стороной.
Безопасная передача данных по сети, которая сама не является безопасной, предполагает шифрование передаваемой информации. Будем предполагать, что каждая из сторон, участвующих в обмене, способна шифровать и дешифровать данные. Протокол Нидхэма-Шрёдера может работать как для симметричной, так и несимметричной схем шифрования (с общим секретным ключом и с двумя парами ключей, соответственно). Будем также считать, что злоумышленник может подключить свою ЭВМ в любую точку пути, по которому происходит обмен и, таким образом, способен перехватить, воспроизвести или исказить любое сообщение. ЭВМ же субъектов обмена и сервер аутентификации предполагаются защищенными от вторжения.
Сервер аутентификации может предоставить идентификационную информацию, вычисляемую на основе секретного ключа субъекта аутентификации.
Сначала рассмотрим вариант с использованием симметричного шифрования/дешифрования (один ключ).
При схеме шифрования с одним ключом, предполагается, что секретный ключ известен обоим субъектам обмена (А и В) и серверу аутентификации. Инициатором обмена будем считать субъекта А. Сообщения, посылаемые от А к В, могут быть дешифрованы только В и субъект В должен быть уверен, что сообщение пришло именно от А. В начале предположим, что оба субъекта находятся в области действия общего сервера аутентификации (AS). AS знает секретные ключи субъектов А и В (KA и KB, соответственно).
Обмен начинается с того, что субъект А генерирует свой идентификатор IA1, который будет использоваться только один раз. Первое сообщение, посылаемое от A к AS, содержит:
|
A® AS: |
(A, B, IA1) | (1) |
|
A® AS: |
(A, B, IA1)KA | (1.1) |
Далее AS посылает субъекту А следующее сообщение:
|
AS® A: |
(IA1, B, CK, {CK, A}KB)KA | (1.2) |
Так как выражение (IA1, B, CK, {CK, A}KB) зашифровано ключом КА, то только субъект А может его дешифровать и прочесть. Субъект А проверяет наличие идентификатора IA1 (это подтверждает то, что данное сообщение является откликом на сообщение А), и имени субъекта, с которым А намерен обмениваться данными (В). В результате дешифровки сообщения от AS А получает во владение рабочий ключ СК. Наличие В в сообщение является обязательным. В противном случае злоумышленник может заменить В на, например, Х в сообщении (1), и в дальнейшем А будет взаимодействовать с Х а не с В, сам того не подозревая.
Заметим, что часть текста {CK, A}KB субъект А прочесть не может.
Если все прошло нормально, субъект А посылает В следующее сообщение:
|
A® B: |
{CK, A}KB | (1.3) |
|
B® A: |
{IB}CK | (1.4) |
|
A® B: |
{IB-1}CK | (1.5) |
|
A® B: |
{CK, A}KB, {IA2}CK | (1.3a) |
| B® A: |
{IA2 –1, IB}CK | (1.4a) |
Предполагается, что субъекты А и В вычислили пары ключей (PKA-SKA) и (PKB-SKB), соответственно. Имена ключей, начинающиеся с буквы P, относятся к общедоступным ключам (public), а имена, начинающиеся с буквы S, - к секретным. Инициатором, как и в предыдущем случае, будем считать субъект А. Обмен начинается с посылки AS запроса открытого ключа В (PKB).
|
A® AS: |
(A, B) | (2.1) |
|
AS® A: |
(PKB, B)SKAS | (2.2) |
Шифрование данных с использованием ключа SKAS не гарантирует конфиденциальности, но исключает модификацию сообщения по дороге (ведь никто посторонний не знает ключ SKAS). Важно, чтобы субъект А был уверен, что он получил именно PKB, а не что-то иное. Следующим шагом будет посылка сообщения от А к В:
|
A® B: |
{IA, A}PKB | (2.3) |
|
B® AS: |
B, A | (2.4) |
| AS® B: |
{PKA, A}SKAS | (2.5) |
|
B® A: |
{IA, IB}PKA | (2.6) |
| A® B: |
{ IB }PKB | (2.7) |
Так как открытые ключи общедоступны, во многих случая для обеспечения большей достоверности следует использовать шифрование типа:
{{сообщение}SKA}SKB.
В реальной жизни субъекты не всегда могут находиться в пределах зоны ответственности одного общего сервера аутентификации. По этой причине в общем случае каждый из субъектов может иметь свой сервер аутентификации (ASA и ASB). Так как и в этом варианте перед субъектом А стоит задача сформировать для В сообщение типа {CK, A}KB (шаг 1.3). В вычисление таких выражений будут вовлечены оба сервера, так как только ASA может шифровать объекты посредством ключа КА, и только ASB может воспользоваться ключом КВ. Не исключается необходимость обеспечения безопасного обмена между AS. Примерами такого обмена могут служить операции, завершающие сессию аутентификации:
|
ASA® ASB: |
(CK, A, B, IA1) | (1.11) |
| ASB® ASA: |
(CK, A)KB, IA1, A | (1.12) |
При работе с открытыми ключами возможно непосредственное обращение А к ASB, если субъект А владеет общедоступным ключом PKASB. По минимуму аутентификация при асимметричной схеме шифрования требует пересылки трех сообщений.
Протокол Нидхэма-Шрёдера пригоден и для работы с электронными подписями. Электронная подпись, как обычно, формируется на основе дайджеста D (например, MD5) пересылаемого документа. Сначала рассмотрим вариант с традиционной схемой шифрования. Субъект А начинает передачу с посылки AS сообщения:
|
A® AS: |
(A, {D}KA) | (3.1) |
|
AS® A: |
{A, D}KAS | (3.2) |
|
B® AS: |
B, {A, D}KAS | (3.3) |
|
AS® B: |
{A, D}KB | 3.4) |
В случае варианта шифрования с общедоступными ключами схема электронной подписи упрощается. В этом варианте можно даже не формировать дайджест можно послать текст, зашифрованный сначала секретным ключом А, а затем с привлечением общедоступного ключа В.
|
A® B: |
{ (текст)SKA }PKB |
В настоящее время разработан улучшенный протокол Нидхэма-Шрёдера (см.
http://dimacs.rutgers.edu/Workshops/Security/program2/dedecker/node4.html).
[1] Roger M. Needham and Michael D. Schroeder, Using Encryption for Authentication in Large Networks of Computers. Communication of the ACM, V.21, N12, December 1978.
Протокол ядра NetWare (NCP)
4.2.1.3 Протокол ядра NetWare (NCP)
NCP представляет собой язык общения серверов и клиентов в среде NetWare. NCP-пакет вкладывается в SPX. Рабочие станции передают свои запросы на запись или чтение файлов, на создание очереди заданий, на поиск в дисковых каталогах и т.д. в виде NCP-сообщений. Прежде чем клиент пошлет NCP-запрос, он должен подключиться к серверу и выдать заявку на формирование NCP-канала связи. Сервер в ответ на этот запрос присылает отклик, в котором содержится подтверждение создания такого канала связи, если запрос удовлетворен. Каждому запросу должен соответствовать отклик. Формат NCP-запроса показан на Рисунок 4.2.1.3.1.
Протокол новостей NNTP
4.5.7 Протокол новостей NNTP
Современное общество предъявляет весьма жесткие требования ко времени получения событийной информации. Это могут быть технические новинки, политические новости, уведомления о событиях (произошедших или грядущих) и т.д. Одной из форм оперативной рассылки и получения информации является электронная почта (в частности система LISTSERV). В таких системах помимо воли клиента в его почтовом ящике, как правило, скапливается огромное количество сообщений. Причем в настоящее время здесь нет пока каких-либо механизмов фильтрации. Несколько иное решение предлагает протокол NNTP и сеть рассылки новостей USENET (cм. RFC-0977, Network News Transfer Protocol, B. Kantor, P.Lapsley. and RFC-1036, Standard for interchange of USENET messages, M.R. Horton, R. Adams). В USENET системе сообщение запоминается в базе данных сервера, а не в почтовых ящиках подписчиков. Региональный депозитарий снабжается специальным программным обеспечением, которое позволяет подписчику отбирать статьи, представляющие для него интерес. Система имеет индексацию, облегчающую поиск, и удаление устаревших статей.
Для кластеров ЭВМ, объединенных ETHERNET (или другой быстродействующей локальной сетью) представляется целесообразным сконцентрировать функции хранения и распределения новостей в одном узле. При этом клиент может запросить любую статью тогда, когда это ему нужно, и он не обязан предоставлять ресурсы для хранения копий статей. Учитывая то, что даже в небольшой локальной сети обычно достаточно много клиентов-подписчиков такая схема позволяет сэкономить достаточно большой объем дискового пространства. Следует учитывать, что интегральный поток новостей сегодня превышает 300 Мбайт в сутки.
Сервер новостей должен размещаться в локальной сети, так как именно в этом случае время доступа минимально. Этот сервер должен заниматься сбором новостей и созданием необходимых индексных файлов. При большом числе ЭВМ такая схема дает значительную экономию дискового пространства.
NNTP представляет собой протокол для рассылки, подписки, поиска и доставки новостей на основе надежного протокола поточного типа (например, TCP) с использованием схемы клиент-сервер.
NNTP сконструирован так, что статья, записанная в одном из серверов, становится доступной для всех подписчиков-клиентов.
Протокол NNTP предполагает применения стандартных сообщений, формат которых следует рекомендациям RFC 850. NNTP-сервер обычно работает в фоновом режиме. В больших сетях, где число клиентов велико, возможно использование нескольких серверов новостей, которые образуют иерархическую систему. При этом клиент сначала пытается подключиться к ближайшему серверу. При неуспехе соединение либо абортируется, либо переадресуется другому серверу.
Единицей хранения на сервере является статья. Статьи составляют содержательную часть пересылаемых сообщений. В NNTP предусмотрены команды, которые обеспечивают непосредственный обмен статьями между взаимодействующими узлами (более эффективно, чем это позволяет, например, UUCP).
Традиционный метод рассылки новостей предполагает распространение статей от узла к узлу, так что каждый сервер пересылает другому все новости, которые имеет. При этом неизбежно дублирование, связанное с этим увеличение трафика и повышенный расход ресурсов ЭВМ. Но такая схема предельно проста и вполне оправдана, когда обмен новостями происходит один раз в сутки (дубликаты статей могут быть отфильтрованы позднее).
При использовании NNTP ЭВМ, обменивающиеся новостями, пользуются интерактивным механизмом в процессе принятия решения о том, какие статьи следует передать. При этом ЭВМ контактирует с одним или несколькими серверами новостей. Процедура начинается с запроса о формировании новых групп новостей, для чего выдается команда NEWGROUPS. Далее клиент делает запрос о наличии новых статей из групп, представляющих интерес (команда NEWNEWS). В ответ сервер высылает список статей, а клиент может запросить их присылку, если он их не имеет. В заключение клиент может сообщить серверу, какие новые статьи он получил в последнее время.
Сервер новостей, специфицированный в NNTP, использует поточный обмен (подобный TCP), а также набор команд и откликов, схожий с SMTP.
Этот сервер является единственным интерфейсом между программами и базами данных, хранящими новости. Он не выполняет взаимодействия с пользователем или каких-либо операций презентационного уровня. Эти функции передаются программам клиента, которые имеют исчерпывающую информацию о среде. При работе через Интернет в рамках протокола TCP используется порт 119. На команды, посылаемые клиентом, предусмотрены текстовые и статусные отклики. Всякая сессия начинается с процедуры установления соединения между клиентом и сервером по инициативе клиента (например, с использованием протокола TCP).
Текст может посылаться только после цифрового статусного отклика. Текст имеет вид последовательности строк, каждая из которых завершается парой символов CR-LF. В конце текста всегда посылается строка, содержащая один символ (.), за которым следует CR-LF (как и в SMTP).
Если исходный текст содержит точку в начале строки, то она перед посылкой должна быть задублирована. Таким образом, клиент должен просматривать первые символы каждой полученной строки и, если это одиночная точка, прерывать дальнейший прием текста. Предполагается, что текстовый отклик будет отображен на дисплее пользователя, в то время как командно-статусный отклик интерпретируется программой клиента.
Статусный отклик представляет собой реакцию сервера на команду, полученную от клиента. Строки статусного отклика начинаются с 3-значного десятичного кода, достаточного для описания любого отклика. Некоторые коды являются предшественниками последующего текстового отклика. Первая цифра говорит об успехе, ошибке или процессе исполнения команды.
| 1xx | Информационное сообщение |
| 2xx | Команда ok |
| 3xx | Команда корректна, можно продолжать обмен. |
| 4xx | Команда корректна, но не может быть выполнена по какой-то причине. |
| 5xx | Команда неприменима, неверна или произошла серьезная ошибка в программе. |
| x0x | Соединение, установка режима, прочие сообщения |
| x1x | Выбор группы новостей |
| x2x | Выбор статьи |
| x3x | Функции распределения |
| x4x | Отправка адресату |
| x8x | Нестандартное (частное применение) расширение |
| x9x | Отладочный вывод |
/p> Конкретное значение кодов отклика можно найти только в описании конкретной команды. Ниже приведен список кодов общего назначения, которые могут быть получены в любое время.
Некоторые статусные отклики могут иметь параметры (числа или имена). Число и тип параметров фиксировано для каждого конкретного отклика. Параметры отделяются от кода отклика и друг от друга одиночным пробелом. Все цифровые параметры имеют десятичное представление и могут начинаться с нулей. Все строковые параметры начинаются после пробела и завершаются пробелом или символьной парой CR-LF, то есть не могут содержать в себе пробелов. Любой текст, который не является параметром отклика, должен отделяться от последнего параметра, если таковой имеется, пробелом и завершаться пробелом.
Не специфицированные коды-отклики могут использоваться для специфических новых команд. Такой код должен относиться к категории x8x (см. таблицу, приведенную выше). Применение не специфицированных откликов для стандартных команд запрещено.
Коды категории x9x зарезервированы для отладочных целей. Так как большинство отладочных откликов можно рассматривать как информационные сообщения, для отладочных выдач зарезервирован диапазон кодов 190-199.
Ниже приведен список сообщений общего назначения, которые может послать NNTP сервер. Эти отклики не привязаны к каким-то конкретным командам и могут быть присланы в результате сбоя или каких-то других необычных обстоятельств.
Вообще говоря, коды 1xx могут игнорироваться; коды 200 или 201 посылаются при начальном подключении к NNTP серверу в зависимости от наличия разрешения пересылки. Код 400 отправляется, когда NNTP сервер прерывает обслуживание, например по запросу оператора, а коды 5xx указывают на то, что процедура не будет выполнена, по какой-то необычной причине.
| 100 | Поясняющий текст |
| 190 – 199 | Отладочный вывод |
| 200 | Сервер готов – отправка разрешена |
| 201 | Сервер готов – отправка запрещена |
| 400 | Обслуживание прерывается |
| 500 | Команда не распознана |
| 501 | Синтаксическая ошибка в команде |
| 502 | Доступ ограничен или нет разрешения |
| 503 | Ошибка в программе – команда не выполнена |
/p> Команды записываются в этом документе прописными буквами, хотя NNTP сервер игнорирует регистр, в котором они напечатаны. Параметры команд, помещенные в квадратные скобки, являются опционными. Длина команды не должна превышать 512 байт.
Команды ARTICLE, BODY, HEAD и STAT
Существует две формы команды ARTICLE (и соответственно команд BODY, HEAD, и STAT), каждая из которых использует различные методы спецификации извлекаемой статьи. Когда за командой ARTICLE следует идентификатор сообщения в угольных скобках ("<" и ">"), используется первая форма команды; когда же имеется цифровой параметр или нет параметра совсем, реализуется вторая форма. Текст статьи присылается в виде текстового отклика.
Команды HEAD и BODY идентичны команде ARTICLE за исключением того, что они возвращают соответственно только строки заголовка или основной текст статьи.
Команда STAT похожа на команду ARTICLE за исключением того, что не присылается никакого текста. Выбирая номер сообщения в пределах группы, команда STAT служит для установки указателя статьи без пересылки какого-либо текста. Возвращаемый отклик содержит идентификатор сообщения. Использование команды STAT для выбора статей по их идентификатору вполне работоспособно, хотя и не слишком эффективно, так как такой отбор не изменяет текущий указатель статьи.
ARTICLE <message-id>
Команда отображает заголовок, пустую строку и текст заданной статьи. Идентификатор сообщения (message-ID) представляет собой идентификатор, представленный в заголовке статьи. Предполагается, что клиент получит идентификатор сообщения из списка, предоставляемого командой NEWNEWS. Команда не изменяет указателя текущей статьи.
ARTICLE [nnn]
Отображает заголовок, пустую строку и текст текущей или специфицированной статьи. Опционный параметр nnn представляет собой числовой идентификатор статьи (номер) в текущей группе новостей. Он должен быть выбран из диапазона, который был выдан при выборе группы. Если этого параметра нет, предполагается текущая статья.
Эта команда устанавливает указатель текущей статьи, если номер статьи указан корректно.
Откликом на команду будет номер текущей статьи, строка-идентификатор сообщения и собственно текст статьи. Присылаемая строка идентификатора сообщения представляет собой последовательность символов, заключенную в угловые скобки, которая извлечена из заголовка статьи (согласно RFC-850). Если идентификаторная строка заголовка в статье отсутствует, в угловых скобках будет записан нуль.
Так как поле идентификатора сообщения для каждой статьи уникально, оно может использоваться для поиска и удаления статей-дубликатов.
Отклики:
220 n <a> article retrieved – далее следует заголовок и сама статья (n = номер статьи, <a> = message-id)
221 n <a> article retrieved – далее следует заголовок
222 n <a> article retrieved – далее следует текст статьи
223 n <a> article retrieved – текст запрашивается отдельно
412 no newsgroup has been selected
420 no current article has been selected
423 no such article number in this group
430 no such article found
Команда GROUP ggg
Обязательный параметр ggg представляет собой имя группы новостей, которая должна быть выбрана. Список доступных групп новостей может быть получен с помощью команды LIST.
Отклик на успешный выбор группы возвращает номера первой и последней статьи в группе и оценку общего числа статей в группе. Оценка может быть и не вполне корректной, она равна или превосходит реальное число статей.
Когда с помощью данной команды группа выбрана, внутренний указатель статьи устанавливается на первую запись в группе. Если выбрана несуществующая группа, остается в силе выбор предыдущей группы. При наборе имени группы выбранный регистр (строчные или прописные буквы) не играет роли.
Отклики:
211 n f l s group selected
(n = оценка числа статей в группе; f = номер первой статьи в группе,
l = номер последней статьи в группе; s = имя группы.)
411 no such news group
Команда HELP
Команда дает краткое описание команд, которые может воспринять сервер.
Отклик на команду имеет текстовую форму и завершается строкой с одиночной точкой в начале.
Отклик: 100 help далее следует текст
Команда IHAVE <messageid>
Команда IHAVE информирует сервер о том, что клиент владеет статьей с идентификационным кодом <messageid>. Если сервер хочет скопировать статью, он пришлет отклик, предлагающий клиенту прислать ее. Если же сервер по какой-либо причине не хочет, чтобы ему прислали копию этой статьи (например, он ее уже имеет), он оповещает клиента об этом в своем отклике.
Если запрошена передача статьи, клиент должен выслать полный текст статьи, включая заголовок. Сервер в этом случае пришлет отклик, уведомляющий об успехе или неудаче этой операции.
Эта процедура отличается от команды POST в том, что последняя предназначена для пересылки полученных извне статей. Сервер может и не пересылать полученную статью другим серверам, в этом случае будут переданы коды ошибок 436 или 437.
Причиной отказа в рассылке может стать неверный код группы, ошибка в заголовке, неприемлемая длина статьи или ограничения дискового пространства. Обычно эти ограничения связаны с конфигурацией программного обеспечения на сервере.
Отклики:
235 article transferred ok
335 send article to be transferred. Завершение последовательностью <CR-LF>.<CR-LF>
435 article not wanted – статью посылать не следует
436 transfer failed – попытайтесь еще раз позднее
437 article rejected – и не пытайтесь
Так как некоторые серверы новостей не могут немедленно принять решение относительно рассылки конкретной статьи, прием статьи подтверждается (код 235), а позднее она может быть молча выброшена. Такое решение не идеально, возможно оно будет пересмотрено позднее.
Команда LAST
Внутренний указатель на статью устанавливается на предшествующую запись в текущей группе. Если указатель уже установлен на первую статью, отправляется сообщение об ошибке, а указатель остается неизменным.
Отклик содержит текущий номер статьи и ее идентификатор.
Отклики:
223 n a article retrieved – выборочно запрашивает текст
(n = номер статьи, a = уникальный идентификатор статьи)
412 no newsgroup selected
420 no current article has been selected
422 no previous article in this group
Команда LIST
Присылает список доступных групп новостей. Каждой группе новостей соответствует строка в следующем формате:
group last first p
где <group> название группы новостей, <last> номер последней известной статьи в данной группе, <first> номер первой статьи в группе, и <p> может быть либо 'y' либо 'n', указывая на наличие или отсутствие разрешения на рассылку соответственно.
Поля <first> и <last> являются числовыми. Они могут начинаться с нулей. Если код поля <last> превосходит код поля <first>, в файле данной группы новостей нет ни одной статьи.
Обратите внимание на то, что рассылка может быть запрещена клиенту, хотя команда LIST указывает на то, что она разрешена для данной группы новостей. Флаг рассылки существует для каждой группы новостей, так как некоторые группы подвергаются редактированию или обобщению и по этой причине не могут рассылаться. Присылаемая статья сначала по почте пересылается посреднику-редактору, который может осуществить ее рассылку. Это не зависит от права рассылки, предоставленного клиенту NNTP-сервером.
Заметьте, что пустой список может быть вполне корректным откликом и означает, что в данный момент на сервере нет новостей.
| Отклик: | 215 далее следует список групп новостей |
Список групп новостей создан с <date и time> будет представлен в том же формате, что и в случае команды LIST.
Дата посылается в виде 6 цифр в формате ГГММДД, где ГГ последние две цифры года, MM – номер месяца (с нулем в начале, если требуется) и ДД номер дня в месяце. Дополнение для года берется из предположения о ближайшем тысячелетии, так 86 предполагает 1986, 30 - 2030, 99 - 1999, а 00 – 2000 годы.
Время должно характеризоваться также 6 цифрами в формате ЧЧMMСС, где ЧЧ – часы с начала суток в 24-часовом исчислении, MM минуты 00-59, а СС секунды 00-59.
Временная зона определяется сервером, в противном случае появляется символьная комбинация "GMT", в этом случае и время и дата привязаны к нулевому меридиану.
Опционный параметр "distributions" представляет собой список групп рассылки, заключенный в угловые скобки. Если параметр задан, рассылаемая часть новых групп новостей будет сравниваться с данным списком, и только при совпадении включается в список. Если необходимо использовать более одного такого фильтра, то они разделяются друг от друга запятыми в пределах угловых скобок.
| Отклик: | 231 далее следует список новых групп |
Команда формирует список идентификаторов статей для заданной группы новостей, с датой после указанной. Для каждого идентификатора сообщения в списке выделяется одна строка. Список завершается строкой с одиночным символом точки, за которым следует CR-LF. Дата и время задаются в том же формате, что и для команды NEWGROUPS.
Для расширения зоны поиска в имени группы новостей можно использовать символ "*". Программа может подставить вместо звездочки любую комбинацию символов. Если вместо имени группы подставлен символ звездочка, поиск будет проведен по всем группам новостей.
Если звездочка в имени группы отсутствует, новые статьи будут искаться только в группе, имя которой приведено в качестве параметра запроса. Имя группы должно быть взято из списка доступных групп. Допускается спецификация нескольких групп (имена разделяются запятыми). После последнего имени группы не должно быть запятой.
Для отрицания соответствия может использоваться восклицательный знак. Это можно использовать для селективного исключения определенных групп новостей с целью сокращения размера списка. Например, спецификация групп "net.*,mod.*,!mod.map.*" определяет, что следует просмотреть все статьи в группах net.<что-то> и mod.<что-то> за исключением mod.map.<что-то>. Восклицательный знак должен использоваться непосредственно перед первым символом выбранного имени группы новостей.
Опционный параметр "distributions" представляет собой список групп рассылки, заключенный в треугольные скобки. Если этот параметр задан, производится отбор статей, соответствующих категориям, приведенным в списке distribution.
Заметьте, что пустой список является вполне допустимым откликом и означает отсутствие новых статей.
| Отклик: | 230 далее следует список идентификаторов новых статей |
Команда перемещает указатель текущей статьи на следующую запись в текущей группе новостей. Если в группе нет больше статей, посылается сообщение об ошибке, а указатель текущей статьи остается не измененным.
В качестве отклика на команду возвращается номер текущей статьи и идентификатор сообщения. Никаких текстовых сообщений не посылается.
Отклики:
223 n a article retrieved, где n = номер статьи, a = уникальный идентификатор статьи
412 no newsgroup selected
420 no current article has been selected
421 no next article in this group
Команда POST
Если рассылка разрешена, в качестве отклика присылается код 340, который указывает, что статью, предназначенную для рассылки, можно присылать. Код отклика 440 указывает, что рассылка запрещена по причинам, зависящим от инсталляции.
Если рассылка разрешена, статья должна быть представлена в формате, описанном в RFC-850, и должна включать в себя все необходимые строки заголовка. После передачи заголовка и текста статьи от клиента к серверу последующий отклик будет свидетельствовать об успехе или неудаче доставки.
Сервер не осуществляет какой-либо фильтрации текста, и он в неизмененном виде будет рассылаться.
Отклики:
240 article posted ok
340 send article to be posted. Конец отмечается последовательностью <CR-LF>.<CR-LF>
440 posting not allowed
441 posting failed
Команда QUIT
Сервер подтверждает получение команды QUIT и затем закрывает канал связи с клиентом. Эта команда предоставляет клиенту корректную возможность сообщить NNTP-серверу, что все операции завершены и сессия закончена.
Если клиент просто разорвет связь, сервер должен также прекратить попытки взаимодействовать с клиентом.
| Отклик: | 205 closing connection - goodbye! |
Команда сообщает серверу, что он связывается не с пользователем, а с обслуживающим сервером (slave). Эта команда позволяет разделить случаи соединения сервера с отдельным пользователем и промежуточными обслуживающими серверами. Это может использоваться для предоставления приоритета запросам от таких клиентов, так как они обслуживают многих пользователей. Это может быть также использовано при возникновении проблем с внутренними ресурсами сервера, когда он может разорвать связи с некоторыми клиентами, сохраняя каналы с обслуживающими серверами. В NNTP-серверах, где приоритетное обслуживание не предусмотрено, команда должна все равно распознаваться и подтверждаться ее получение
| Отклик: | 202 slave status noted |
Пример 1 – относительный доступ с помощью команды NEXT
| S: | прослушивает порт 119 TCP |
| C: | запрашивает соединения к порту 119 TCP |
| S: | 200 wombatvax news server ready - posting ok |
| C: | LIST |
| S: | 215 далее следует список групп новостей |
| S: | net.wombats 00543 00501 y |
| S: | net.unix-wizards 10125 10011 y |
| S: | net.idiots 00100 00001 n |
| S: | . |
| C: | GROUP net.unix-wizards |
| S: | 211 104 10011 10125 net.unix-wizards group selected |
(Клиент выбирает статью для чтения)
| C: | STAT 10110 |
| S: | 223 10110 <23445@sdcsvax.ARPA> article retrieved - statistics |
<23445@sdcsvax.ARPA>)
(Клиент просматривает заголовок)
| C: | HEAD |
| S: | 221 10110 <23445@sdcsvax.ARPA> article retrieved – далее следует заголовок |
| S: | . |
| C: | BODY |
| S: | 222 10110 <23445@sdcsvax.ARPA> article retrieved – далее следует текст статьи |
| S: | . |
/p> ( Клиент хочет просмотреть следующую статью данной группы)
| C: | NEXT |
| S: | 223 10113 <21495@nudebch.uucp> article retrieved - statistics only (статья 10113 является следующей в группе) |
| C: | QUIT |
| S: | 205 goodbye. |
| S: | прослушивает порт 119 TCP |
| C: | запрашивает соединения к порту 119 TCP |
| S: | 201 UCB-VAX netnews server ready – рассылка запрещена |
| C: | GROUP msgs |
| S: | 211 103 402 504 msgs Your new group is msgs |
| C: | ARTICLE 401 |
| S: | 423 No such article in this newsgroup |
| C: | ARTICLE 402 |
| S: | 220 402 <4105@ucbvax.ARPA> Article retrieved |
| S: | Следует заголовок текст и статьи |
| S: | . |
| C: | HEAD 403 |
| S: | 221 403 <3108@mcvax.UUCP> Article retrieved, header follows |
| S: | Следует заголовок статьи |
| S: | . |
| C: | QUIT |
| S: | 205 UCB-VAX news server closing connection. Goodbye. |
| S: | прослушивает порт 119 TCP |
| C: | запрашивает соединения к порту 119 TCP |
| S: | 200 Imaginary Institute News Server ready (posting ok) |
| C: | NEWGROUPS 850403 020000 |
| S: | 231 Далее следуют группы новостей после 03/04/85 02:00:00 follow |
| S: | net.music.gdead |
| S: | net.games.sources |
| S: | . |
| C: | GROUP net.music.gdead |
| S: | 211 0 1 1 net.music.gdead Newsgroup selected |
| C: | QUIT |
| S: | 205 Imaginary Institute news server ceasing service. Bye! |
| S: | прослушивает порт 119 TCP |
| C: | запрашивает соединения к порту 119 TCP |
| S: | 200 BANZAIVAX news server ready, рассылка разрешена. |
| C: | POST |
| S: | 340 Continue posting; Period on a line by itself to end |
| C: | Передает статью в формате RFC850 |
| C: | . |
| S: | 240 Article posted successfully. |
| C: | QUIT |
| S: | 205 BANZAIVAX closing connection. Goodbye. |
Протоколы Novell (IPX/SPX)
4.2.1 Протоколы Novell (IPX/SPX)
| Номер раздела | Название раздела | Объем в страницах | Объем в кбайт |
| 4.2.1 | Протоколы Novell (IPX/SPX) | 1 | 5 |
| 4.2.1.1 | IPX-протокол | 4 | 60 |
| 4.2.1.2 | SPX-протокол | 2 | 26 |
| 4.2.1.3 | Протокол ядра NetWare (NCP) | 3 | 18 |
| 4.2.1.4 | Протокол межсетевой передачи больших пакетов (LIP) | 3 | 24 |
| 4.2.1.5 | Служба каталогов NetWare (NDS) | 4 | 52 |
Межсетевой протокол IPX - (Internetwork Packet eXchange; Novell (См. также А.В.Фролов, Г.В.Фролов, “Локальные сети персональных компьютеров. Использование протоколов IPX, SPX, NETBIOS. Москва, “Диалог-МИФИ”, 1993), [13]) соответствует сетевому уровню модели ISO, до какой-то степени это аналог IP-протокола в Интернет. IPX-протокол может работать совместно с SPX при обеспечении обменов, ориентированных на соединение, где гарантируется доставка информации. IPX произошел от протокола XNS (Xerox Network Services) и имеет ряд уникальных черт. Так IPX может использовать различные схемы инкапсуляции в зависимости от физической сетевой среды. В операционной среде MS-DOS за реализацию протокола IPX отвечает программа IPX.COM или IPXODI.COM. Оболочка же системы NetWare (NETX.COM) и DOS Requester (VLM.COM) используют протокол IPX для пересылки запросов файл-серверу.
Первоначально пакеты Novell инкапсулировались в кадры IEEE 802.3. В настоящее время схема инкапсуляции поддерживает 802.2 и протокол SNAP (Sub-Network Access Protocol).
Работа с сервером новостей
4.5.7.1 Работа с сервером новостей
Основные группы новостей, рассылаемые по всему миру, это: alt, comp, misc, news, rec, sci, soc и talk. Существует много других базовых категорий новостей, например, bionet, biz, vmsnet, которые рассылаются также повсеместно или в рамках какого-то региона или организации (например, ieee), а также коммерческие (например, clari). Последние категории рассылаются только ограниченно. Сообщения многих Bitnet LISTSERV серверов также рассылаются в виде новостей и относятся к категории bit.
Наиболее важные группы новостей:
| Имя группы новостей | Тематика |
| alt | Много различных тем (альтернативные группы новостей) |
| bionet | Биология |
| bit | Многие темы: из подписного листа Bitnet |
| biz | Бизнес, маркетинг, реклама |
| comp | ЭВМ |
| ddn | Defense Data Network (сеть министерства обороны) |
| gnu | Фонд общедоступного программного обеспечения, проект GNU |
| ieee | Institute of Electrical and Electronics Engineers (Институт инженеров электриков и электронщиков) |
| info | Многие темы из листа рассылки Университета Иллинойса |
| k12 | От детских садов до высшей школы |
| misc | Все, что не попадает в одну из категорий news о самой Usenet |
| rec | Хобби, искусство, развлечения, отдых |
| sci | Науки всех направлений |
| soc | Социальная тематика |
| talk | Обсуждение полемических тем |
| u3b | AT&T 3B ЭВМ |
| vmsnet | DEC VAX/VMS и DECNET системы |
Базовые категории разбиваются на более чем 1200 групп новостей по различным вопросам и темам (от образования для инвалидов до Star Trek и от науки об окружающей среде до политики в странах бывшего Советского Союза).
Качество дискуссий в этой среде не гарантируется. Некоторые группы имеют посредников, которые просматривают сообщения перед рассылкой. Usenet была разработана в 1979 году для системы UNIX. В настоящее время в сети новостей работает несколько тысяч узлов, охватывающих практически весь земной шар.
Новости доступны как через локальный сервер, так и через телефонные коммутируемые сети. Программы для поддержки локального сервера новостей доступны в Интернет, UUCP, EARN/Bitnet и Fidonet. Если вам доступна только электронная почта, тогда для вас Usenet не доступна. Однако, многие группы новостей подключены к спискам почтовой рассылки и вы можете подписаться на них. Для этого шлите запрос в LISTSERV@AMERICAN.EDU со строкой: GET NETGATE GATELIST. Более того, многие документы, которые появляются в новостях, доступны по электронной почте в mail-server@rtfm.mit.edu. Для получения руководства по применению в поле subject напишите HELP.
Команды (базовые), используемые при выборе групп новостей
Основные команды
| h | Отобразить справочную информацию; |
| q | quit rn (чтение новостей) - прерывание чтения новостей; |
| x | quit rn, изменения, внесенные в ваш файл .newsrc, не будут сохранены; |
| v | Показать, c какой версией rn вы работаете. RN – прикладная программа, предназначенная для просмотра новостей. |
| Space | Выполнение команды по умолчанию; |
| y | Чтение текущей группы новостей; |
| - | Тоже самое, что и y, но отображает список тем (subjects); |
| ^N | Переход к следующей нечитанной статье по тому же вопросу; |
| k | Пометить как читанные все статьи по текущей теме (subject). |
| = | Выдать список всех нечитанных статей; |
| число | Переход к статье с данным номером; |
| # | Отобразить номер последней статьи. |
| n | Переход к следующей группе новостей с нечитанными статьями; |
| p | Переход к предшествующей группе с нечитанными статьями; |
| P | Назад к следующей статье читанной или не читанной; |
| ^P | Назад к предыдущей статье по той же теме; |
| ^ | Переход к первой группе новостей с нечитанными статьями; |
| ^R | Заново вывести на экран текущую статью; |
| $ | Переход в конец списка групп новостей; |
| g группа новостей | Переход к заданной группе новостей; |
| /эталон | Поиск в прямом направлении группы, содержащей эталон; |
| ? эталон | Поиск в обратном направлении группы, содержащей эталон; |
| / | Поиск в прямом направлении предшествующего эталона; |
| G | Повторить поиск с направлением вперед; |
| ? | Поиск в обратном направлении предшествующего эталона; |
| u | Ликвидация подписки на текущую группу новостей; |
| v | Заново вывести на экран текущую статью вместе с заголовком; |
| l эталон | Выдача списка неподписанных групп, содержащих эталон; |
| L | Выдача состояния групп новостей в файле .newsrc; |
| ^L | Заново вывести на экран текущую страницу; |
| b | Возврат назад на одну страницу; |
| c | Пометить все новости в группе как прочитанные; |
| A | Пренебречь всеми изменениями в данной группе новостей; |
| j | Пометить статью, как прочитанную и перейти в конец; |
| ^X | Декодировать текущую статью, используя ROT-13; |
| X | Декодировать текущую страницу, используя ROT-13; |
/p> Отклик на статью
| r | Послать отклик автору статьи по электронной почте; |
| R | То же, что и r, но в ответ включается исходный текст; |
| f | Запуск программы Pnews для написания статьи отклика; |
| F | То же, что и f, но с включением текста исходной статьи. |
| s файл | Запись статьи в файл; |
| w файл | То же, что и s, но без записи заголовка. |
| ! команда | Выполнить данную Unix-команду; |
| ! | Прервать исполнение rn и уйти в Shell. |
Существует поддержка Usenet в самых разных операционных системах: Unix, VMS, MS-DOS, OS/2, Macintosh, MVS, а также в различных средах: MS-Windows, X-Windows, Windows-NT, Emacs. Имеются интерфейсы для системы USENET и для электронной почты. Многие, реально почти все, программные продукты обеспечивают следующие возможности:
Подписка на группы новостей. Это означает, что именно новости данной группы будут немедленно доступны и вы сможете их просмотреть, когда пожелаете.
Аннулирование подписки на группы новостей. Группа удаляется из вашего списка.
Чтение оглавления групп новостей. Ваш локальный сервер выдает вам оглавление новостей и отслеживает, какие из них вы уже читали.
Нить дискуссии. Вы можете отслеживать оглавления групп новостей, имеющих отношение к одной и той же теме или предмету.
Посылка сообщения в группу новостей. Вы можете участвовать в дискуссии, ваш сервер новостей знает, куда послать ваше сообщение.
Отклик на сообщение. Вы можете послать отклик на любое сообщение (это часто называется follow-up [отклик]) или обратиться к автору сообщения (это обычно называется replay [ответ]).
Выбрав с помощью стрелки группу новостей и нажав клавишу <Enter>, вы получите оглавление статей в группе. Символ "+" указывает на то, что не все сообщения в цепочке были прочитаны. После выбора конкретной статьи вам будет предоставлено ее содержание.
Когда вы введете TIN (программа просмотра новостей), вы получите список групп новостей, на которые вы подписались:
tin 1.2 PL2 [UNIX] (c) Copyright 1991-93 Iain Lea.
(загрузка просмотрщика новостей)
Reading news active file...
Reading attributes file...
Reading newsgroups file... h=help
| Group | Selection (3658) | (выдается базовое меню групп новостей) |
| 1 | 26 | alt.0d | |
| 2 | 72 | alt.1d ? | |
| 3 | 50426 | alt.2600 | |
| 4 | 79 | alt.3d | Dis |
| 5 | 496 | alt.abortion.inequity | Pat |
| 6 | 83 | alt.abuse.recovery | ? |
| 7 | 41087 | alt.activism | Act |
| 8 | 231 | alt.activism.d | A p |
| 9 | 106 | alt.activism.death-penalty | |
| 10 | 208 | alt.adoption | Ado |
| 11 | 37 | alt.aeffle.und.pferdle | Ger |
| 12 | 40 | alt.agriculture.fruit | ? |
| 13 | 26 | alt.agriculture.misc | Gen |
| 14 | 8 | alt.aldus.freehand | ? |
| 15 | 5 | alt.aldus.misc | ? |
| 16 | 78 | alt.aldus.pagemaker | ? |
| <n>=set current to n, | TAB=next unread, | /=search pattern, | c)atchup, | g)oto, |
| j=line down, | k=line up, | h)elp, | m)ove, | q)uit, |
| r=toggle all/unread, | s)ubscribe, | S)ub pattern, | u)nsubscribe, | U)nsub |
| pattern, | y)ank in/out |
Goto newsgroup [comp.mail.misc]> comp.inforsystems.gopher
(получаем новое меню, выбранная тема помечена стрелкой на левом поле)
Group Selection (3658)
| 1825 | 189 comp.graphics.animation Tec | |
| 1826 | 26 comp.graphics.visualization Inf | |
| 1827 | 19 comp.groupware Har | |
| 1828 | 180 comp.groupware.lotus-notes.misc | |
| 1829 | 151 comp.home.automation | |
| 1830 | comp.home.misc | |
| 1831 | 53 comp.human-factors Iss | |
| 1832 | 27 comp.infosystems Any | |
| 1833 | comp.infosystems.announce | |
| 1834 | 130 comp.infosystems.gis All | |
| --> | 1835 | 8 comp.infosystems.gopher Dis |
| 1836 | 1 comp.infosystems.interpedia | |
| 1837 | comp.infosystems.kiosks | |
| 1838 | 27 comp.infosystems.wais The | |
| 1839 | 302 comp.infosystems.www.misc | |
| 1840 | 16 comp.internet.library Dis |
| 1 | + 3 mime-type Wolfgang Zekoll | |
| 2 | + Harmony Binary Release 1.1 Mansuet Gaisbauer | |
| 3 | + IRD Internet Gopher sites file Fritz Bohnet | |
| --> | 4 | + telnet via gopher Monty FullerDC |
| 5 | + WWW shop of British fine tea from Williamson webmaster@sswi.com | |
| 6 | + WWW shop of Billy Riggs' sermon tapes webmaster@sswi.com |
Does anyone have a list of sights through which one can access telnet by way of gopher? Thanks for any help. Sincerely, Monty Fuller
Посмотрим следующее сообщение (пункт 5):
Hi,
I would like to invite everybody to visit our WWW shop of British fine tea from Williamson & Magor: Assam, Celebration Blend, Darjeeling, Earl Grey, English Breakfast, Lifeboat.
Go to http://www.sswi.com/, and look under "Shopping Mall": Have a nice holiday. Web Master
http://www.sswi.com/ (может быть интересно для любителей хорошего чая).
В документе 3 найдем полезную информацию об адресе, где лежит список Gopher-серверов:
I have found the IRD Gopher sites file to be a very useful tool for searching the Internet. For those of you who want to have a look, here is the download site:
http://www.mbmarktcons.com/mbmarkt/irdhome.htm
or via FTP from:
ftp://ftp.mbmarktcons.com/pub/mbmarkt/ird/Fritz
Вернувшись назад в предыдущее меню и выбрав позицию 1838 (comp.infosystems.wais), мы получим другой список документов:
comp.infosystems.wais (19T 26A 0K 0H R)
| 1 | + searching for an underscore ("_") Thomas Carter |
| 2 | + Multi-field search w/freeWAIS-sf Paul Bingman |
| 3 | + 2 Help, compiling FreeWAIS under Sun OS 4.1.4 Adrian Blakey |
| 4 | + Harmony Binary Release 1.1 Mansuet Gaisbauer |
| 5 | + 2 freewais-sf BIO patches? Tak |
| 6 | + Indiceing single letters with freeWAIS-sf-2.0 B. D.O.Adams |
| 7 | + Wais database and html page question? Hans Baartmans |
| 8 | + Help on Virtual Warehousing Daniel Chang |
| 9 | + Question on freeWAIS and SFgate Anna Lee |
| 10 | + 2 Combining numeric fields in boolean search Frances Blomeley |
| 11 | + 2 Indexing PDF files Robert M. Ioffe |
| 12 | + extending length of filenames in freewais-sf Brenda Levesque |
| 13 | + Question: Timestamp problem with wais? Hans Baartmans |
| 14 | + 3 sockets.c – make errors Jason Wilkes |
| 15 | + freewais, wais, and Solaris Philippe Cuif |
| 16 | + 2 freeWAIS-sf Can't compile on BSD Jack Ellis |
Серверы новостей взаимодействуют друг с другом согласно стандартным протоколам, некоторые из которых описаны в Internet RFC. В настоящее время в этом списке имеются:
RFC-977 описывает NNTP (Network News Transfer Protocol)
RFC-1036 определяет формат статей Usenet.
Некоторые группы новостей содержат статьи и дискуссионные материалы по использованию Usenet. Например: news.announce.newusers, news.answers и news.newusers.questions. Многие статьи, которые появляются в этих группах новостей доступны также с помощью анонимного FTP по адресу rtfm.mit.edu или по электронной почте по адресу: mail-server@rtfm.mit.edu.
Различные сетевые топологические схемы
Рисунок 4.2. Различные сетевые топологические схемы
Современные вычислительные системы используют и другие топологии: решетки (А), кубы (В), гипердеревья (Б), гиперкубы и т.д. (см. Рисунок 4.3). Но так как некоторые вычислительные системы (кластеры) базируются на сетевых технологиях, я привожу и такие примеры. В некоторых системах топология может настраиваться на решаемую задачу.
Сетевой протокол времени NTP
4.4.15 Сетевой протокол времени NTP
Время – самый важный и невосполнимый ресурс любого человека. Проблема эта занимала людей всегда, и уже более 4 тысяч лет люди пытаются как-то упорядочить учет расходования этого ресурса, создавая различные календарные системы и устройства измерения времени. Календарные системы древнего мира отражали сельскохозяйственные, политические и ритуальные нужды, характерные для того времени. Астрономические наблюдения для установления зимнего и летнего солнцестояния производились еще 4000 лет тому назад. Проблема создания календаря возникала только в обществах, где государственная стабильность поддерживалась в течение достаточно долгого времени (Китай, Египет, государство Майя). В 14-ом столетии до Рождества Христова в Китае была определена длительность солнечного года - 365.25 дней, а лунный месяц - 29.5 дней. Солнечно-лунный календарь действовал на ближнем востоке (за исключением Египта) и в Греции, начиная с 3-го тысячелетия до нашей эры. Ранние календари использовали либо 13 лунных месяцев по 28 дней или 12 месяцев с чередующейся протяженностью 29 и 30 дней.
Древнеегипетский календарь имел 12 30-дневных лунных месяцев, но был привязан к сезонному появлению звезды Сириус (sirius – sothis). Для того чтобы примирить этот календарь с солнечным годом, был изобретен гражданский календарь, в котором добавлено 5 дней, доводящих длительность года до 365 дней. Однако со временем было замечено, что гражданский год примерно на одну четверть дня короче, чем солнечный год. Выбранная длительность года обеспечивала полное совпадение с солнечным годом раз за 1460 лет. Этот период называется циклом Сотиса (sothic-цикл). Так же как и shang chinese, древние египтяне установили длительность солнечного года равной 365,25 дней, что с точностью 11 минут совпадает с результатами современных вычислений. В 432 году до рождества Христа, около столетия после китайцев греческий астроном Метон вычислил, что 110 лунных месяцев по 29 дней и 125 лунных месяцев по 30 дней соответствуют 6940 солнечным дням, что лишь немного превышает 19 лет. 19-летний цикл, названный циклом Метона, установил длительность лунного месяца равной 29,532 солнечных дней, что с точностью 2 минут совпадает результатами современных измерений.
В древнем Риме использовался лунный календарь. Юлий Цезарь пригласилалександрийского астронома Сосигенса, который разработал календарь (который по понятным причинам стал называться юлианским), принятый в 46 году до Рождества Христова. Календарь содержал 365 дней в году с добавлением одного дня каждые 4 года. Однако первые 36 лет по ошибке дополнительный день добавлялся каждые три года. В результате набежало лишних три дня, которые пришлось компенсировать вплоть до 8 года нашей эры.
Семидневная неделя была введена лишь в четвертом столетии нашей эры императором Константином I.
Во время романской эры 15-летний цикл переписи использовался при исчислении налогов. Последовательность имен дней недели воспроизводится через 28 лет, этот период называется солнечным циклом. Таким образом, учитывая 28-летний солнечный цикл, 19-летний цикл Метона и 15-летний переписи, получаем суперцикл протяженностью 7980-лет, называемый юлианской эрой, которая начинается в 4713 году до рождества христова.
К 1545 году расхождение между юлианским календарем и солнечным годом достигло 10 дней. В 1582, астрономы Кристофер Клавиус и Луиджи Лилио предложили новую схему календаря. Папа Грегорий XIII выпусти указ, где среди прочего указывалось, что в году содержится 365.2422 дней. Для того чтобы более точно аппроксимировать эту новую величину, только столетние годы, которые делятся без остатка на 400, объявляются високосными, что предполагает длительность года 365,2425 дней. В настоящее время григорианский календарь принят большинством стран мира.
Для того чтобы мерить расширение вселенной или распад протона необходимо стандартную схему нумерации дней. По решению Международного астрономического Союза был принят стандарт на секунду и юлианская система нумерации дней (jdn). Стандартный день содержит 86,400 стандартных секунд, а стандартный год состоит из 365,25 стандартных дней.
В схеме (JDN), предложенной в 1583 французским ученым Джозефом Юлиусом Скалигером, JDN 0.0 соответствует 12 часам (полдень) первого дня юлианской эры - 1 января 4713 до нашей эры.
Годы до нашей эры подсчитываются согласно юлианскому календарю, в то время как годы нашей эры нумеруются по григорианскому календарю. 1 января 1 года после рождества христова в григорианском календаре соответствует 3 января 1 года юлианского календаря [DER90], в JDN 1.721.426,0 день соответствует 12 часам первого дня нашей эры.
Калиброванный эталон времени, например атомные часы, довольно сложное и дорогостоящее устройство, требующее квалифицированного обслуживания. По этой причине многие пользователи не могут позволить себе такие издержки и вынуждены обращаться к услугам удаленных эталонов. Это может быть первичный эталон, размещенный где-то в локальной сети, или радио-часы. Условия доступа к сети уже предполагают наличие определенной дисперсии для времени доставки калибровочной информации. Если же эталон размещен далеко в Интернет, значения задержки и дисперсии могут возрасти многократно. Для обеспечения большей надежности калибровки обычно используют несколько эталонов, а для снижения влияния временных разбросов привлекают довольно сложные алгоритмы усреднения.
Сетевой протокол задания времени NTP (network time protocol; Network Time Protocol Version 3 Specification, Implementation and Analysis, David L. Mills, RFC-1305, March 1992) служит для осуществления синхронизации работы различных процессов в серверах и программах клиента. Он определяет архитектуру, алгоритмы, объекты и протоколы, используемые для указанных целей. NTP был впервые определен в документе RFC-958 [MIL85c], но с тех пор несколько раз переделан и усовершенствован (RFC-1119 [MIL89]). Протокол использует для транспортных целей UDP [POS80]. Целью протокола является обеспечение максимально возможной точности и надежности, несмотря на значительный разброс задержек при прохождении через большое число промежуточных маршрутизаторов.
Протокол NTP обеспечивает механизмы синхронизации с точностью до наносекунд. Протокол предлагает средства для определения характеристик и оценки ошибок локальных часов и временного сервера, который осуществляет синхронизацию.
Предусмотрены возможности работы с иерархически распределенными первичными эталонами, такими как синхронизуемые радио-часы.
Точность, достижимая с помощью NTP, сильно зависит от точности локальных часов и характерных скрытых задержек. Алгоритм коррекции временной шкалы включает внесение задержек, коррекцию частоты часов и ряд механизмов, позволяющих достичь точности порядка нескольких миллисекунд, даже после длительных периодов, когда потеряна связь с синхронизирующими источниками.
Существует ряд механизмов в Интернет, которые позволяют передавать и записывать время, когда произошло какое-то событие. Это протокол daytime [POS83a], time protocol [POS83b], сообщения ICMP “временная метка” [DAR81b] и опция IP “временная метка” [SU81].
Маршрутный протокол fuzzball [MIL83b], иногда называемый hellospeak, встраивает синхронизацию непосредственно в алгоритм маршрутного протокола. Он не является протоколом из стека IP.
Юниксовский (4.3BSD) времязадающий демон [GUS85a] измеряет временные сдвиги различных клиентских процессов и рассылает им соответствующие поправки.
В этой модели сервер определен с помощью алгоритма выбора [GUS85b], который исключает ситуации, где сервер не выбран или выбрано более одного сервера. Процесс выбора требует возможности рассылки широковещательных сообщений.
Архитектура системы
Сети передачи данных Методы доступа
4 Сети передачи данных. Методы доступа
| Номер раздела | Название раздела | Объем в страницах | Объем в кбайт |
| 4 | Сети передачи данных. Методы доступа | 14 | 13 |
| 4.1 | Локальные сети (обзор) | 1 | 1 |
| 4.2 | Наложенные сети | 1 | 6 |
| 4.3 | Региональные сети | 1 | 5 |
| 4.4 | Интернет | 3 | 2 |
| 4.5 | Процедуры Интернет | 1 | 9 |
| 4.6 | Электронная торговля в Интернет | 7 | 60 |
Топология
Среди топологических схем наиболее популярными являются (см. Рисунок 4.1):
Шина
Звезда
Кольцо
Многокаскадные и многосвязные сети (См. раздел 4.1.10; 41\ban_4110.doc)
Система поиска NETFIND
4.5.8.4 Система поиска NETFIND
| Адрес сервера | Страна | Адрес сервера | Страна |
| archie.ua | Австралия | bruno.cs.colorado.edu | США |
| dino.conicit.ve | Венесуэла | ds.internic.net | США |
| lincoln.technet.sg | Сингапур | macs.ee.mcgill.ca | Канада |
| malloco.ing.puc.cl | Чили | monolith.cc.ic.ac.uk | Англия |
| mudhoney.micro.umn.edu | США | netfind.oc.com | США |
| netfind.sjsu.edu | США | netfind.icm.edu.pl | Польша |
| netfind.vslib.cz | Чехия | nic.nm.kr | Корея |
| nic.uakom.sk | Словакия | redmont.cis.uab.edu | США |
| netfind.fnet.fr | Франция | eis.calstate.edu | США |
Место работы искомого человека может быть описано ключевыми словами. NETFIND просматривает свою базу данных seed, чтобы найти домен, отвечающий критериям отбора. Список таких доменов отображается и вам предлагается выбрать из них 1-3. Если обнаружено более 100 доменов, NETFIND выдаст имена некоторых из них и предложит повторить поиск с более жесткими условиями. Можно использовать часть названия организации или домена в качестве эталона в процессе поиска. При использовании более чем одного эталона можно применить знак логической операции AND. По завершении поиска или при прерывании его с помощью ^C NETFIND выдает полученный результат. Предлагаются не только данные о домене или организации, но и даты последних входов искомого человека в систему. Обращение к NETFIND имеет формат:
netfind <опции> фамилия (имя) место работы (ключевые слова)
где допустимы следующие опции:
-h |
Указывает NETFIND обойти фазу поиска домена и немедленно начать поиск индивидуальной ЭВМ в базе seed. Эта функция редко используется обычными пользователями |
| -s | Исключает применение протокола SMTP при поиске. Поиск происходит немного быстрее, но дает не полную информацию, так как не все ЭВМ пользователей поддерживают протокол finger |
| -t | Сообщает сколько случилось таймаутов. -T опция устанавливает время таймаута равным заданному числу секунд, что позволяет увеличить это время в некоторых случаях |
| -D | Устанавливает максимальное число доменов, где будет проводиться поиск. По умолчанию эта величина равна 3 (большее значение устанавливать не рекомендуется). Правильный выбор этого числа заметно ускоряет процесс поиска и снижает нагрузку на сеть. |
| -H | Устанавливает максимальное число ЭВМ, где будет проводиться поиск. По умолчанию это число равно 50. Устанавливать большую величину не рекомендуется |
| -m | Отображает измерительную информацию. Если не указано имя файла, то вывод производится в файл stderr |
| -d | Позволяет устанавливать различные классы отладочного вывода (в stderr), используя соответствующую букву для каждого из них, напр. -dsf. Могут использоваться любые комбинации этих букв |
| c: | Отображает управляющие сообщения (позволяет контролировать, какой точки достигла программа). |
| f: | Отображает сообщения, связанные с finger. |
| h: | Выдает список ЭВМ, найденных в базе данных seed. |
| m: | Отображает сообщения протокола SMTP. |
| n: | Отображает сообщения о неисправности сети. |
| r: | Отображает имена ЭВМ из базы seed, которые были отброшены из-за выбора search scope. |
| s: | Отображает системные сообщения. |
| t: | Отображает сообщения, связанные с thrread. |
При выдаче имени домена или ЭВМ можно выдавать эту информацию без разделительных точек, например, cs colorado edu. NETFIND для входа не требует каких-либо слов-паролей, кроме NETFIND. Воспользуемся услугами сервера nic.uakom.sk:
| tn nic.uakom.sk | (обращение к серверу в Словакии) | |
| SunOS UNIX (nic) | (произошло соединение) | |
| login: | netfind | (подключаемся к NETFIND-серверу, далее следует текст, выдаваемый сервером) |
Slovakia, Banska Bystrica
Welcome to the Netfind server
questions/problems : Lubos.Elias@uakom.sk
Alternate Netfind servers:
I think that your terminal can display 24 lines. If this is wrong, please enter the "Options" menu and set the correct number of lines. (Если ваш терминал не работает с 24 строками, обратитесь в раздел "Options" и установите верное значение).
| Top level choices: | (Выдано базовое меню) |
| 1. Help (Запрос справочной информации) | |
| 2. Search (Поиск) | |
| 3. Seed database lookup (просмотр базы данных SEED) | |
| 4. Options (Дополнительные возможности) | |
| 5. Quit (exit server) (Уход из сервера) | |
| --> | 1 (Запрошена справочная информация) |
| 1. Netfind search help (Работа с NETFIND) | |
| 2. Usage restrictions (Используемые команды) | |
| 3. Frequently asked questions (Часто задаваемые вопросы) | |
| 4. For more information (Дополнительная информация) | |
| 5. Quit menu (back to top level) (Возврат в предыдущее меню) | |
| --> | 1 (Запрошена информация о работе с NETFIND) |
По имени и приблизительному описанию места работы Netfind пытается найти информацию о данном лице. В качестве имени может быть введена фамилия или имя. Одновременно могут быть выданы ключевые слова: место работы, имя домена, город или страна. Найдя домен, Netfind отображает список доменов и просит вас выбрать от одного до трех из них, где следует провести поиск.
Поиск проходит в два этапа. На первом - Netfind выполняет поиск в каждом из выбранных доменов. На втором этапе проводится более детальное исследование с помощью finger. Имеется возможность прервать поиск с помощью ^C.
По завершении знакомства со справочной информации система возвращается к базовому меню. На этот раз выбираем пункт 2 (Поиск). Система выдает предупреждение:
| NOTE: | Received no responses, and some host or network failures occurred. Maybe try this search again later. (В случае неуспеха можно позднее попытать счастья снова). |
Enter person and keys (blank to exit) --> Burov DESY Germany
(Введено задание на поиск: фамилия, место работы, страна)
Найдено три домена, отвечающие критериям отбора.
Please select at most 3 of the following domains to search:
(предлагается провести поиск по этим трем доменам)
| 0. | desy.de (desy zeus central data acquisition, germany) |
| 1. | dsyibm.desy.de (desy, hamburg, germany) |
| 2. | info.desy.de (desy zeus central data acquisition, germany) |
(введен список доменов, где будет проведен поиск)
( 3) SMTP_Finger_Search: checking domain dsyibm.desy.de
( 3) do_connect:
Finger service not available on host dsyibm.desy.de -> cannot do user lookup.
(Поиск с помощью Finger не доступен на dsyibm.desy.de)
( 1) SMTP_Finger_Search: checking domain info.desy.de
( 2) got nameserver operator.desy.de
( 2) got nameserver sun01a.desy.de
( 2) SMTP_Finger_Search: checking domain desy.de
Mail for Sergei Bourov is forwarded to burov@x4u2.desy.de
Поиск завершился успехом - найден адрес, куда пересылается почта для Бурова, далее на экран выводится следующий текст:
NOTE:
this is a domain mail forwarding arrangement to an outside domain, possibly indicating that "burov" has moved to another department or institution. Hence, mail should be addressed to "burov@x4u2.desy.de" (почта должна посылаться Бурову по адресу).
( 1) SMTP_Finger_Search: checking host x4u2.desy.de
SYSTEM: x4u2.desy.de
| Login name: burov In real life: | Sergei Bourov | |
| (Полное имя: Сергей Буров) | ||
| Office: 1d/39, 2081/2747 | Home phone: none |
Last login at Tue Sep 26 09:04 from UNKNOWN@AXDSYB.desy.de
(последний раз входил в систему во вторник 26-го сентября)
No Plan.
FINGER SUMMARY (результат исследования с помощью Finger):
- Remote user queries (finger) were not supported on host(s) searched in the domain 'dsyibm.desy.de'.
- The most promising email address for "burov" based on the above finger search is burov@x4u2.desy.de.
Continue the search ([n]/y) ? --> n (хотим ли мы продолжить поиск?)
При удаленном доступе к NETFIND имеется служба HELP. В секции каталога DOC обычно имеется также файл "часто задаваемые вопросы" (frequently asked questions - FAQ). Большую пользу может оказать статья "Experience with a Semantically Cognizant Internet White Pages Directory Tool", написанная M.F.Schwartz и P.G.Tsirigotis, Journal of Internetworking Research and Experience, март 1991, стр. 23-50. Существует список адресов подписчиков NETFIND. Для включения вас в этот список необходимо послать запрос по адресу netfind-users-request@cs.colorado.edu, где в тексте сообщения (не в строке subject!) написать: subscribe netfind-users. Исчерпывающую информацию о NETFIND можно найти посредством:
FTP ftp.cs.colorado.edu /pub/cs/distribs/netfind
WWW www.earn.net gnrt/netfind.html alpha.acast.nova.edu netfind.html
Telnet ds.internic.net (Login: netfind).
Служба каталогов NetWare (NDS)
4.2.1.5 Служба каталогов NetWare (NDS)
С точки зрения службы каталогов netware (NDS - netware directory services) сеть - это не совокупность ЭВМ, а интегрированная информационная среда. При регистрации в сети клиент получает доступ ко всем ее ресурсам. Для повышения надежности и сокращения времени доступа к сети база данных службы каталогов netware распределена по сети. Отдельные фрагменты базы данных могут располагаться на разных серверах, и могут быть задублированы на нескольких серверах, имеются специальные сетевые средства для синхронизации изменений в этих секциях. Все эти вещи порождают в сети дополнительный трафик, ведь необходимо сравнивать содержимое секций базы данных, их обновление, читать и изменять записи и т.д. Одной из важнейших функций службы каталогов является синхронизация работы ее частей. Синхронизация предполагает определение порядка операций по обслуживанию каталога. В службе каталогов все серверы делятся на:
Главный эталонный временной сервер (устанавливает время для вторичных серверов и клиентов, время устанавливается супервизором, при наличии в сети таких серверов применение первичных и эталонных временных серверов не допускается);
Первичный сервер (синхронизует сетевое время, по крайней мере, с еще одним первичным или эталонным сервером, время устанавливается по выбранному сетевому времени);
Эталонный сервер (задает время для всех остальных серверов и клиентов, синхронизируется от внешнего источника, например, службы времени, первичные серверы должны согласовывать свое время с эталонным сервером);
Вторичный сервер (синхронизируется от главного эталонного, первичного или просто эталонного сервера).
Существует пять функций NCP, которые поддерживают взаимодействие со службой каталогов Netware. Имеются также функции службы каталогов. Коды функций вставляются в пакеты, посылаемые службой каталогов, и служат в качестве субфункций основных NCP-операций.
Ссылки
Ссылки
|
[ABA89] |
Abate, et al. AT&T's new approach to the synchronization of telecommunication networks. IEEE Communications Magazine (April 1989), 35-45. |
|
[ALL74a] |
Allan, D.W., J.H. Shoaf and D. Halford. Statistics of time and frequency data analysis. In: Blair, B.E. (Ed.). Time and Frequency Theory and Fundamentals. National Bureau of Standards Monograph 140, U.S. Department of Commerce, 1974, 151-204. |
|
[ALL74b] |
Allan, D.W., J.E. Gray and H.E. Machlan. The National Bureau of Standards atomic time scale: generation, stability, accuracy and accessibility. In: Blair, B.E. (Ed.). Time and Frequency Theory and Fundamentals. National Bureau of Standards Monograph 140, U.S. Department of Commerce, 1974, 205-231. |
|
[BEL86] |
Bell Communications Research. Digital Synchronization Network Plan. Technical Advisory TA-NPL-000436, 1 November 1986. |
|
[BER87] |
Bertsekas, D., and R. Gallager. Data Networks. Prentice-Hall, Englewood Cliffs, NJ, 1987. |
|
[BLA74] |
Blair, B.E. Time and frequency dissemination: an overview of principles and techniques. In: Blair, B.E. (Ed.). Time and Frequency Theory and Fundamentals. National Bureau of Standards Monograph 140, U.S. Department of Commerce, 1974, 233-314. |
|
[BRA80] |
Braun, W.B. Short term frequency effects in networks of coupled oscillators. IEEE Trans. Communications COM-28, 8 (August 1980), 1269-1275 |
|
[COL88] |
Cole, R., and C. Foxcroft. An experiment in clock synchronisation. The Computer Journal 31, 6 (1988), 496-502. |
|
[DAR81a] |
Defense Advanced Research Projects Agency. Internet Protocol. DARPA Network Working Group Report RFC-791, USC Information Sciences Institute, September 1981. |
|
[DAR81b] |
Defense Advanced Research Projects Agency. Internet Control Message Protocol. DARPA Network Working Group Report RFC-792, USC Information Sciences Institute, September 1981. |
|
[DEC89] |
Digital Time Service Functional Specification Version T.1.0.5. Digital Equipment Corporation, 1989 |
|
[DER90] |
Dershowitz, N., and E.M. Reingold. Calendrical Calculations. Software Practice and Experience 20, 9 (September 1990), 899-928. |
|
[FRA82] |
Frank, R.L. History of LORAN-C. Navigation 29, 1 (Spring 1982). |
|
[GUS84] |
Gusella, R., and S. Zatti. TEMPO - A network time controller for a distributed Berkeley UNIX system. IEEE Distributed Processing Technical Committee Newsletter 6, NoSI-2 (June 1984), 7-15. Also in: Proc. Summer USENIX Conference (June 1984, Salt Lake City). |
|
[GUS85a] |
Gusella, R., and S. Zatti. The Berkeley UNIX 4.3BSD time synchronization protocol: protocol specification. Technical Report UCB/CSD 85/250, University of California, Berkeley, June 1985. |
|
[GUS85b] |
Gusella, R., and S. Zatti. An election algorithm for a distributed clock synchronization program. Technical Report UCB/CSD 86/275, University of California, Berkeley, December 1985. |
|
[HAL84] |
Halpern, J.Y., B. Simons, R. Strong and D. Dolly. Fault-tolerant clock synchronization. Proc. Third Annual ACM Symposium on Principles of Distributed Computing (August 1984), 89-102. |
|
[JOR85] |
Jordan, E.C. (Ed). Reference Data for Engineers, Seventh Edition. H.W. Sams & Co., New York, 1985. |
|
[KOP87] |
Kopetz, H., and W. Ochsenreiter. Clock synchronization in distributed real-time systems. IEEE Trans. Computers C-36, 8 (August 1987), 933-939. |
|
[LAM78] |
Lamport, L., Time, clocks and the ordering of events in a distributed system. Comm. ACM 21, 7 (July 1978), 558-565. |
|
[LAM85] |
Lamport, L., and P.M. Melliar-Smith. Synchronizing clocks in the presence of faults. J. ACM 32, 1 (January 1985), 52-78. |
|
[LIN80] |
Lindsay, W.C., and A.V. Kantak. Network synchronization of random signals. IEEE Trans. Communications COM-28, 8 (August 1980), 1260-1266. |
|
[LUN84] |
Lundelius, J., and N.A. Lynch. A new fault-tolerant algorithm for clock synchronization. Proc. Third Annual ACM Symposium on Principles of Distributed Computing (August 1984), 75-88. |
|
[MAR85] |
Marzullo, K., and S. Owicki. Maintaining the time in a distributed system. ACM Operating Systems Review 19, 3 (July 1985), 44-54. |
|
[MIL81a] |
Mills, D.L. Time Synchronization in DCNET Hosts. DARPA Internet Project Report IEN-173, COMSAT Laboratories, February 1981. |
|
[MIL81b] |
Mills, D.L. DCNET Internet Clock Service. DARPA Network Working Group Report RFC-778, COMSAT Laboratories, April 1981. |
|
[MIL83a] |
Mills, D.L. Internet Delay Experiments. DARPA Network Working Group Report RFC-889, M/A-COM Linkabit, December 1983. |
|
[MIL83b] |
Mills, D.L. DCN local-network protocols. DARPA Network Working Group Report RFC-891, M/A-COM Linkabit, December 1983. |
|
[MIL85a] |
Mills, D.L. Algorithms for synchronizing network clocks. DARPA Network Working Group Report RFC-956, M/A-COM Linkabit, September 1985. |
|
[MIL85b] |
Mills, D.L. Experiments in network clock synchronization. DARPA Network Working Group Report RFC-957, M/A-COM Linkabit, September 1985. |
|
[MIL85c] |
Mills, D.L. Network Time Protocol (NTP). DARPA Network Working Group Report RFC-958, M/A-COM Linkabit, September 1985. |
|
[MIL88a] |
Mills, D.L. Network Time Protocol (version 1) - specification and implementation. DARPA Network Working Group Report RFC-1059, University of Delaware, July 1988. |
|
[MIL88b] |
Mills, D.L. The Fuzzball. Proc. ACM SIGCOMM 88 Symposium (Palo Alto, CA, August 1988), 115-122. |
|
[MIL89] |
Mills, D.L. Network Time Protocol (version 2) - specification and implementation. DARPA Network Working Group Report RFC-1119, University of Delaware, September 1989. |
|
[MIL90] |
Mills, D.L. Measured performance of the Network Time Protocol in the Internet system. ACM Computer Communication Review 20, 1 (January 1990), 65-75. |
|
[MIL91a] |
Mills, D.L. Internet time synchronization: the Network Time Protocol. IEEE Trans. Communications 39, 10 (October 1991), 1482-1493. |
|
[MIL91b] |
Mills, D.L. On the chronology and metrology of computer network timescales and their application to the Network Time Protocol. ACM Computer Communications Review 21, 5 (October 1991), 8-17. |
|
[MIT80] |
Mitra, D. Network synchronization: analysis of a hybrid of master-slave and mutual synchronization. IEEE Trans. Communications COM-28, 8 (August 1980), 1245-1259. |
|
[NBS77] |
Data Encryption Standard. Federal Information Processing Standards Publication 46. National Bureau of Standards, U.S. Department of Commerce, 1977. |
|
[NBS79] |
Time and Frequency Dissemination Services. NBS Special Publication 432, U.S. Department of Commerce, 1979 |
|
[NBS80] |
DES Modes of Operation. Federal Information Processing Standards Publication 81. National Bureau of Standards, U.S. Department of Commerce, December 1980. |
|
[POS80] |
Postel, J. User Datagram Protocol. DARPA Network Working Group Report RFC-768, USC Information Sciences Institute, August 1980. |
|
[POS83a] |
Postel, J. Daytime protocol. DARPA Network Working Group Report RFC-867, USC Information Sciences Institute, May 1983. |
|
[POS83b] |
Postel, J. Time protocol. DARPA Network Working Group Report RFC-868, USC Information Sciences Institute, May 1983. |
|
[RIC88] |
Rickert, N.W. Non Byzantine clock synchronization - a programming experiment. ACM Operating Systems Review 22, 1 (January 1988), 73-78. |
|
[SCH86] |
Schneider, F.B. A paradigm for reliable clock synchronization. Department of Computer Science Technical Report TR 86-735, Cornell University, February 1986. |
|
[SMI86] |
Smith, J. Modern Communications Circuits. McGraw-Hill, New York, NY, 1986. |
|
[SRI87] |
Srikanth, T.K., and S. Toueg. Optimal clock synchronization. J. ACM 34, 3 (July 1987), 626-645. |
|
[STE88] |
Steiner, J.G., C. Neuman, and J.I. Schiller. Kerberos: an authentication service for open network systems. Proc. Winter USENIX Conference (February 1988). |
|
[SU81] |
Su, Z. A specification of the Internet protocol (IP) timestamp option. DARPA Network Working Group Report RFC-781. SRI International, May 1981. |
|
[TRI86] |
Tripathi, S.K., and S.H. Chang. ETempo: a clock synchronization algorithm for hierarchical LANs - implementation and measurements. Systems Research Center Technical Report TR-86-48, University of Maryland, 1986. |
|
[VAN84] |
Van Dierendonck, A.J., and W.C. Melton. Applications of time transfer using NAVSTAR GPS. In: Global Positioning System, Papers Published in Navigation, Vol. II, Institute of Navigation, Washington, DC, 1984. |
|
[VAS78] |
Vass, E.R. OMEGA navigation system: present status and plans 1977-1980. Navigation 25, 1 (Spring 1978). |
функций и субфункций службы каталогов представлена ниже
Таблица (4.2.1.5.1) функций и субфункций службы каталогов представлена ниже.
Коду операции управляющего сообщения
Таблица 4.4.15.5. Коду операции управляющего сообщения
|
Код |
Функция |
0 |
Зарезервировано |
1 |
чтение статуса команда/отклик |
2 |
чтение переменной команда/отклик |
3 |
запись переменной команда/отклик |
4 |
чтение переменных часов команда/отклик |
5 |
запись переменных часов команда/отклик |
6 |
установка адреса/порта trap команда/отклик |
7 |
отклик на Trap |
8-31 |
Зарезервировано на будущее |
Порядковый номер (Sequence) - 16-битовое поле, определяющее номер запроса или отклика, и облегчающее определения их соответствия.
Статус - 16-битовое поле, содержащее код статуса системы, партнера или часов.
Идентификатор ассоциации (Association ID) - 16-битовое поле, несущее в себе идентификатор ассоциации.
Смещение (Offset) - 16-битовое поле, определяющее положение первого октета поля данных в сообщении, передаваемом в нескольких дейтограммах (позиция задается в октетах).
Длина (Count) - 16-битовое поле, определяющее длину поля данных в октетах.
Данные - это поле содержит информацию сообщения, как для команды, так и для отклика. Максимальное число октетов в поле данных равно 468.
Аутентификатор (опционно). Поле, содержащие аутентификационную информацию. Используется лишь в случае реализации NTP-аутентификации.
Статусные слова
Статусные слова указывают на текущее состояние системы ассоциации и часов. Эти слова интерпретируются программами сетевого мониторинга и имеют 4 разных 16-битовых форматов. Статусные слова партнеров и системы соответствуют откликам для всех команд за исключением случая чтения/записи переменных часов и установки адреса/порта для TRAP. Идентификатор ассоциации нуль соответствует системным статусным словам, в то время как ненулевой идентификатор указывает на какую-то конкретную ассоциацию. Статусное слово, присланное в ответ на команду чтения или записи переменной часов, указывает на состояние оборудования и кодирующего программного обеспечения.
Системные статусные слова
Системное статусное слово может присутствовать в статусном поле отклика. Системное статусное слово имеет следующий формат.
Индикатор добавления (LI - leap indicator) - двухбитовое поле предупреждения о предстоящем добавлении/вычитании секунды к последней минуте текущего дня. Значения этих битов смотри в таблице 4.4.15.1.
Источник часов (clock source) - 6-битовое поле, указывающее на используемый в данный момент источник синхронизации. Назначение кодов этого поля описано в таблице 4.4.15.6.
Коды идентификаторов часов
Таблица 4.4.15.4. Коды идентификаторов часов
Слой |
Код |
Значение |
0 |
dcn | Протокол маршрутизации dcn |
0 |
dts | Цифровая служба времени (digital time service) |
0 |
nist | Общий модем nist |
0 |
tsp | Временной протокол tsp |
1 |
atom | Атомные часы (калиброванные) |
1 |
vlf | vlf-радио (omega, и пр.) |
1 |
callsign | Общее радио |
1 |
gps | gps УВЧ позиционирование спутников |
1 |
lorc | loran-c радионавигация |
1 |
wwvb | Радио wwvb НЧ (диапазон 5) |
1 |
goes | Спутник goes УВЧ (диапазон 9) |
1 |
wwv | Радио wwv ВЧ (диапазон 7) |
В случае слоя 2 и выше (вторичный эталон) - это 4-октетный IP-адрес партнера, выбранного для синхронизации.
Эталонная временная метка (sys.reftime, peer.reftime, pkt.reftime) - локальное время в формате временных меток, соответствующее моменту последней коррекции показаний часов. Если локальные часы не были синхронизованы, переменная содержит нуль.
Базовая временная метка (peer.org, pkt.org) - локальное время в формате временных меток, соответствующее моменту посылки последнего NTP-сообщения. Если партнер недостижим, переменная принимает нулевое значение.
Временная метка получения (peer.rec, pkt.rec) - локальное время в формате временных меток, соответствующее моменту прихода последнего NTP-сообщения, полученного от партнера. Если партнер недостижим, переменная принимает нулевое значение.
Временная метка передачи (peer.xmt, pkt.xmt) - локальное время в формате временных меток, соответствующее моменту отправки NTP-сообщения.
Системные переменные
Следующие переменные используются операционной системой для синхронизации локальных часов.
Переменная локальные часы (sys.clock) содержит показание локальных часов в формате временных меток. Локальное время получается от аппаратных часов конкретной ЭВМ и дискретно увеличивается с конструктивно заданными приращениями.
Переменная Базовые часы (sys.peer) представляет собой селектор, идентифицирующий используемый источник синхронизации. Обычно это указатель на структуру, содержащую переменные партнера. Значение нуль указывает, что в настоящее время источник синхронизации отсутствует.
Переменные партнера
Ниже перечислены все переменные партнера, которые используются для управления и реализации измерительных процедур.
Бит конфигурации (peer.config) - бит, индицирующий, что ассоциация была сформирована на основе конфигурационной информации и не должна быть расформирована, когда партнер становится недоступен.
Временная метка актуализации (peer.update) - локальное время в формате временной метки, отмечающее момент, когда было получено последнее NTP сообщение. Переменная используется для вычисления дисперсии временного сдвига.
Регистр достижимости (peer.reach) - сдвиговый регистр битов ntp.window, используемых для определения статуса достижимости партнера. Ввод данных производится со стороны младших бит (справа). Партнер считается достижимым, если как минимум один бит этого регистра равен 1.
Таймер партнера (peer.timer) - целочисленный счетчик, используемый для управления интервалом между последовательно посылаемыми NTP-сообщениями. После установки значения счетчика его содержимое уменьшается на 1 (1сек) пока не достигнет нуля. При этом вызывается процедура передачи. Заметим, что работа этого таймера не должна зависеть от локальных часов.
Пакетные переменные
Номер версии (pkt.version) - целое число индицирующее номер версии отправителя. NTP сообщения всегда посылаются с текущим значением версии ntp.version и будут восприняты лишь при условии совпадения кодов версии (ntp.version). Исключения допускаются лишь при смене номера версии.
Переменные фильтра часов
Когда используются фильтры и алгоритмы отбора, дополнительно привлекаются следующие переменные состояния.
Регистр фильтра (peer.filter) - сдвиговый регистр каскадов ntp.shift, где каждый каскад запоминает значения измеренной задержки, смещения и вычисленной дисперсии, соответствующих одному наблюдению. Эти три параметра вводятся со стороны старших разрядов и сдвигаются в направлении младших разрядов (направо). При получении результатов нового наблюдения старые результаты теряются.
Счетчик корректных данных (peer.valid) - целочисленный счетчик, указывающий на корректные образцы, остающиеся в регистре фильтра.
Он используется для определения состояния доступности и для управления увеличением и уменьшением периода рассылки сообщений.
Смещение (peer.offset) - число с фиксированной запятой со знаком, индицирующее значение смещение часов партнера по отношению к локальным часам в секундах.
Задержка (peer.delay) - число с фиксированной запятой со знаком, индицирующее полную циклическую задержку (RTT) часов партнера по отношению к локальным часам с учетом времени распространения сообщения и отклика в сети в секундах. Заметим, что переменная может принимать как положительное, так и отрицательное значение в зависимости от точности часов и накопившейся ошибки смещения.
Дисперсия (peer.dispersion) - число с фиксированной запятой, индицирующее максимальную ошибку часов партнера по отношению к локальным часам с учетом сетевой задержки в секундах. Допускаются только значения больше нуля.
Переменные аутентификации
При использовании механизма аутентификации привлекаются следующие переменные состояния.
Бит разрешения аутентификации (peer.authenable) - бит, указывающий, что ассоциация должна работать в режиме аутентификации.
Бит аутентификации (peer.authentic) - бит, индицирующий то, что последнее сообщение, полученное от партнера, было корректно аутентифицировано.
Идентификатор ключа (peer.hostkeyid, peer.peerkeyid, pkt.keyid) - целое число, идентифицирующее криптографический ключ, использованный при генерации аутентификационного кода сообщения.
Криптографические ключи (sys.key) - набор 64-битных ключей DES. Каждый ключ создается в соответствии с берклиевскими UNIX-распределениями, которые состоят из 8 октетов, где 7 младших бит каждого октета соответствуют битам des 1-7, а старший бит соответствует биту четности DES.
Контрольная крипто-сумма (pkt.check) - криптографическая контрольная сумма, вычисляемая процедурой шифрации.
Параметры
Ниже описаны параметры для всех реализаций, работающих в сети Интернет. Необходимо договориться относительно значений этих параметров для того, чтобы исключить ненужную избыточность и стабилизировать ассоциации партнеров.
Приведенные параметры применимы для всех ассоциаций.
Номер версии (ntp.version) - текущий номер версии NTP (3).
Порт NTP (ntp.port) - стандартный номер порта (123), присвоенный протоколу NTP.
Максимальный номер слоя (ntp.maxstratum) - максимальный номер слоя, который может быть использован при кодировании пакетной переменной. Этот параметр обычно интерпретируется как определение бесконечности (недостижимости для протокола маршрутизации в субсети).
Максимальный возраст часов (ntp.maxage) - максимальный интервал в секундах, в течение которого эталонные часы будут рассматриваться корректными после последней сверки.
Максимальный сбой (ntp.maxskew) - максимальная ошибка смещения, связанная со сбоем локальных часов за время ntp.maxage, в секундах. Отношение ntp.maxskew к ntp.maxage интерпретируется как максимальный сбой, вызванный всей совокупностью факторов.
Максимальное расстояние (ntp.maxdistance) - максимально допустимое расстояние между партнерами при синхронизации с использованием алгоритма отбора.
Минимальный период рассылки (ntp.minpoll) - минимальный период рассылки, допустимый для любого из партнеров в сети Интернет. Этот период выражается в секундах и представляет собой степень 2.
Максимальный период рассылки (ntp.maxpoll) -максимальный период рассылки, допустимый для любого из партнеров в сети Интернет. Этот период выражается в секундах и представляет собой степень 2.
Минимум избранных часов (ntp.minclock) - минимальное число партнеров, необходимое для синхронизации (при использовании алгоритма отбора).
Максимум избранных часов (ntp.maxclock) - максимальное число партнеров, необходимое для организации отбора (при использовании алгоритма селекции).
Минимальная дисперсия (ntp.mindisperse) - минимальное значение приращения дисперсии для каждого из слоев в секундах (при использовании алгоритма фильтрации).
Максимальная дисперсия (ntp.maxdisperse) - максимальная дисперсия в секундах с учетом потерянных данных (при использовании алгоритма фильтрации).
Размер регистра доступности (ntp.window) - размер регистра доступности (peer.reach) в битах.
Размер фильтра (ntp.shift) - размер сдвигового регистра фильтра часов (peer.filter) в каскадах.
Вес фильтра (ntp.filter) - вес, используемый при вычислении дисперсии фильтра (применяется при работе с алгоритмом фильтрации).
Выбранный вес (ntp.select) - вес, используемый при вычислении выбранной дисперсии (применяется при работе алгоритма селекции).
Режимы работы
За исключением широковещательного режима, NTP-ассоциация формируется, когда два партнера обмениваются сообщениями и один или оба из них создает и поддерживает протокольную машину, называемую ассоциацией. Ассоциация может работать в одном из 5 режимов, заданных переменной peer.mode: симметрично активный, симметрично пассивный, клиент, сервер и широковещательный:
Симметрично активный (1). ЭВМ, работающая в этом режиме, периодически посылает сообщения вне зависимости от достижимости или слоя своего партнера. При работе в этом режиме ЭВМ оповещает о своем намерении синхронизовать и быть синхронизованной партнером.
Симметрично пассивный (2). Этот тип ассоциации первоначально создается по прибытии сообщения от партнера, работающего в симметрично активном режиме. Он сохраняется, пока партнер достижим и функционирует в слое ниже или равном данной ЭВМ. В противном случае ассоциация распадается. Однако ассоциация будет существовать до тех пор, пока, по крайней мере, одно сообщение не будет послано в качестве отклика. При работе в этом режиме ЭВМ оповещает о своем намерении синхронизовать и быть синхронизованной партнером.
Клиент (3). ЭВМ, работающая в этом режиме, периодически посылает сообщения вне зависимости от достижимости или слоя своего партнера. При работе в этом режиме ЭВМ, обычно это сетевая рабочая станция, оповещает о своем намерении быть синхронизованной партнером.
Сервер (4). Этот тип ассоциации первоначально создается по прибытии запроса клиента и существует только для отклика на этот запрос. После отклика ассоциация ликвидируется. При работе в этом режиме ЭВМ, обычно рабочая сетевая станция, оповещает о намерении синхронизовать партнера.
Широковещательный (5). ЭВМ, работающая в этом режиме, периодически посылает сообщения вне зависимости от доступности или слоя партнеров. При работе в этом режиме ЭВМ, обычно сетевой сервер времени, который работает в широковещательной среде, оповещает о намерении синхронизовать всех партнеров.
ЭВМ, работающая в режиме клиента, иногда посылает NTP-сообщение ЭВМ, работающей в режиме сервера, например, сразу после перезагрузки и периодически после этого. Сервер откликается, меняя адреса и номера портов, занося необходимую информацию и отправляя сообщение назад клиенту. Серверы не должны хранить какую-либо статусную информацию в паузах между запросами клиента, в то время как клиенты могут варьировать интервалы между NTP сообщениями, для того чтобы удовлетворить локальным требованиям. В этих режимах протокольная машина, описанная в этой статье, может быть существенно упрощена без заметной потери точности или надежности особенно при работе в быстродействующей локальной сети.
В симметричных режимах отличие клиента от сервера практически исчезает. Симметрично пассивный режим предназначен для использования временными серверами, работающими вблизи базовых узлов (нижний слой) субсети синхронизации и со сравнительно большим числом партнеров. В этом режиме идентификации партнера не требуется заранее, так как ассоциация с ее переменными состояния создана, только когда получено NTP-сообщение. Более того, запомненное состояние может быть использовано позднее, когда партнер станет недостижим или будет работать на более высоком уровне и по этой причине будет непригоден в качестве источника синхронизации.
Симметрично активный режим предназначен для использования серверами времени, работающими вблизи оконечных узлов (наивысший слой) синхронизации. Надежный временной сервис обычно может быть реализован с помощью двух партнеров на ближайшем нижележащем слое и одном партнере в том же слое. По этой причине поток сообщений обычно невелик, даже когда связь потеряна, и на каждый запрос приходит отклик об ошибке.
В норме, один партнер работает в активном режиме (симметричный активный, клиент или широковещательный), как это сконфигурировано в стартовом файле, в то время как другие работают в пассивном режиме (симметричный пассивный или сервер), часто без предварительной конфигурации. Однако оба партнера могут быть сконфигурированы для работы в симметричном режиме. Условие ошибки возникает, когда оба партнера работают в одном и том же режиме, но не в симметричном активном. В таких случаях каждый партнер будет игнорировать сообщения, поступающие от другого, и ассоциация, если она существовала, будет ликвидирована из-за недостижимости партнера.
Широковещательный режим предназначен для работы в скоростных локальных сетях с большим числом рабочих станций, где не требуется высокая точность. При типичном сценарии один или более временных серверов LAN периодически посылают широковещательные сообщения рабочим станциям, которые затем определяют время на основе предварительно заданной задержки распространения порядка нескольких миллисекунд.
Обработка событий
Существенные события с точки зрения протокола NTP происходят при истечении времени таймеров партнера (peer.timer), один из которых ориентирован специально на данного партнера в активной ассоциации, а также при получении NTP-сообщения от различных партнеров. Событие может произойти как результат команды оператора или обнаруженной ошибки, такой как отказ первичного эталона.
Обозначения
Алгоритмы фильтрации и селекции NTP используют несколько переменных для хранения значений сдвига часов, RTT и дисперсии. Переменные, относящиеся к партнерам, обычно обозначаются строчными греческими буквами, а для первичного эталона времени используются прописные буквы. Эти алгоритмы базируются на параметре, называемом расстояние синхронизации
(l) и вычисляемом с использованием rtt и дисперсии.
Дисперсия партнера (e) содержит вклады от ошибок измерения (r) и накопления ошибок дрейфа (skew-error).
Каждый раз, когда соответствующие переменные партнеров изменяются, значения дисперсии корректируются.
Ниже приводятся основные определения переменных и формулы их вычисления:
q = peer.offset,
d = peer.delay,
e = peer.dispersion = r + jt + es,
l = e + |d|/2,
где d = rtt, q - сдвиг часов, jt - накопление сбоя, j = ntp.maxskew/ntp.maxage, t - момент времени передачи исходной временной метки (на основе t вычисляется q и d), e
s
- дисперсия фильтра. Переменные, относящиеся к партнеру i, определяются следующим образом:
q i = j i,
d i = peer.rootdelay + d i,
e i = peer.rootdispersion + e
i + j ti
(максимальная дисперсия часов партнера),
li= ei + |di|/2,
Окончательно, предполагая, что для синхронизации выбран i-ый партнер, система переменных определяется следующим образом:
q = комбинированное окончательное смещение (combined final offset),
d = di,
e = ei + ex + q,
l = li,
где ex дисперсия выбора (select dispersion).
Приводимые ниже тексты программ, реализующие вычисления переменных, записаны на условном языке, напоминающем СИ.
Процедура передачи
Процедура передачи запускается, когда таймер партнера станет равным нулю. В режиме клиента с широковещательным сервером сообщения вообще не посылаются. В режиме сервера сообщения посылаются только в качестве отклика на полученные запросы.
Нижеприведенный фрагмент программы инициализирует пакетный буфер и копирует пакетные переменные.
|
pkt.peeraddr | /* копирование системных и партнерских переменных */ |
pkt.peerport
pkt.hostaddr
pkt.hostport
pkt.leap
pkt.version
pkt.mode
pkt.stratum
pkt.poll
pkt.precision
pkt.rootdelay
if (sys.leap = 112 or (sys.clock - sys.reftime) > ntp.maxage)
skew
else
skew j (sys.clock - sys.reftime);
{pkt.rootdispersion
pkt.refid
pkt.reftime
Временная метка передачи pkt.xmt будет использована позднее, для того чтобы проконтролировать отклик. Таким образом, программа должна сохранить точное переданное значение. Кроме того, порядок копирования временных меток должен быть выбран так, чтобы не понизить точность.
|
pkt.org | /* копирование временных меток */ |
pkt.rec
pkt.xmt
peer.xmt
Регистр доступности сдвигается на одну позицию влево, в освободившийся разряд записывается нуль. Если все биты регистра равны нулю, вызывается процедура очистки (clear procedure) для обнуления фильтра часов и выбора, если необходимо, нового источника синхронизации. Если ассоциация не была сконфигурирована при инициализации, то она ликвидируется.
|
peer.reach | /* актуализация доступности */ |
if (peer.reach = 0 and peer.config =0)
begin
ликвидируем ассоциацию;
exit;
endif
Если корректные данные введены в сдвиговый регистр фильтра хотя бы раз за время предыдущих двух периодов рассылки (младший бит peer.reach равен 1), счетчик корректных данных увеличивается на 1. После восьми таких удачных периодов интервал рассылки увеличивается. Процедура выбора часов вызывается, если необходимо заменить источник синхронизации.
| if (peer.reach & 6 ? 0) | /* Проверка младших двух бит */ |
| if (peer.valid | /* получены корректные данные */ |
peer.valid
else peer.hostpoll
else begin
| peer.valid | /* ничего не слышно */ |
peer.hostpoll
call clock-filter(0, 0, ntp.maxdisperse);
| call clock-select; | /* выбираем источник синхронизации */ |
endif
call poll-update;
end transmit procedure;
Процедура получения
Процедура получения выполняется по приходу NTP-сообщения. Она проверяет сообщения, интерпретирует различные режимы и вызывает другие процедуры для фильтрации данных и выбора источника синхронизации. Если номер версии в пакете не соответствует текущей версии, сообщение может быть отброшено. Если получено управляющее сообщение NTP и код режима пакета равен 6 (управление), вызывается процедура управляющего сообщения. IP-адреса отправителя и адресата, а также номера портов устанавливаются соответствующими заданному партнеру. Если соответствия нет, производится новая инсталляция протокольной машины и формируется новая ассоциация.
begin receive procedure
if (pkt.version ? ntp.version>) exit;
#ifdef (control messages implemented)
if (pkt.mode = 6) call control-message;
#endef
| for (all associations) | /* Здесь выполняется управление доступом */ |
match addresses and ports to associations;
if (no matching association)
| call receive-instantiation procedure; | /* создаем ассоциацию */ |
Вызов процедуры дешифровки осуществляется только в случае применения аутентификации.
#ifdef (authentication implemented)
call decrypt;
#endef
Если код режима пакета не равен нулю, он определяет режим на следующем этапе; в противном случае, режим определяется по номеру порта.
| if (pkt.mode = 0) | /* для совместимости со старыми версиями */ |
mode;
else
mode
case (mode, peer.hostmode)
В случае ошибки пакет просто игнорируется, а ассоциация, если она не была предварительно сконфигурирована, ликвидируется.
error: if (peer.config = 0) demobilize association;
break;
В случае recv пакет обрабатывается, а ассоциация помечается как достижимая при условии 5-8 успешных проверок. Если и проверки с первой по 4-ую проходят успешно (данные корректны), вызывается процедура коррекции показания локальных часов. В противном случае, если ассоциация не была предварительно сконфигурирована, она ликвидируется.
| recv: call packet; | /* обработать пакет */ |
| if (valid header) begin | /* если правильный заголовок, актуализовать внутренние часы */ |
peer.reach
if (valid data) call clock-update;
endif
else
if (peer.config = 0) ликвидировать ассоциацию;
break;
В случае xmit, пакет обрабатывается и посылается промежуточный отклик. Ассоциация затем ликвидируется.
| xmit: call packet; | /* обработать пакет */ |
| peer.hostpoll | /* послать немедленно отклик */ |
call poll-update;
call transmit;
if (peer.config = 0) ликвидировать ассоциацию;
break;
В случае pkt, пакет обрабатывается, а ассоциация помечается как достижимая при условии, что тесты 5-8 (правильный заголовок), перечисленные в пакетной процедуре, прошли успешно. Если, кроме того, прошли тесты 1-4 (корректные данные), вызывается процедура коррекции показаний локальных часов. В противном случае, если ассоциация не была предварительно сконфигурирована, она сразу после отклика ликвидируется.
| pkt: call packet; | /* обработка пакета */ |
| if (valid header) begin | /* если заголовок правилен, поправляется показание местных часов */ |
peer.reach
if (valid data) call clock-update;
endif
else if (peer.config = 0) begin
| peer.hostpoll | /* послать немедленно отклик */ |
call poll-update;
call transmit;
ликвидировать ассоциацию;
endif
endcase
end receive procedure;
Пакетная процедура
Пакетная процедура проверяет корректность сообщения, вычисляет задержку/смещение и вызывает другие процедуры для отбора данных и выбора источника синхронизации. Тест 1 требует, чтобы переданная временная метка отличалась от последней, полученной от того же партнера. Тест 2 требует, чтобы исходная временная метка соответствовала последней метке, посланной тому же партнеру. В случае широковещательного режима (5) rtt=0 и полная точность операции передачи времени будет недостижимой. Однако, полученная точность может быть вполне приемлемой для многих целей. Процедура вызова коррекции времени использует в качестве параметра peer.hostpoll (peer.peerpoll может быть изменено).
begin packet procedure
|
peer.rec | /* забрать полученную временную метку */ |
if (pkt.mode ? 5) begin
| test1 | /* Тест 1 */ |
| test2 | /* Тест 2 */ |
endif
else begin
| pkt.org | /* потеря временной метки из-за ошибки */ |
pkt.rec
| test1; | /* ложные тесты */ |
test2;
endif
| peer.org | /* актуализация исходной временной метки */ |
| peer.peerpoll | /* скорректировать период рассылки */ |
call poll-update(peer.hostpoll);
Тест 3 требует, чтобы исходная и полученная временные метки не были равны нулю. Если любая из них равна нулю, ассоциация не синхронизирована или потеряла доступ в одном или обоих направлениях.
test3
rtt и временное смещение по отношению партнера вычисляется следующим образом. Пусть i четное целое число.
Тогда ti-3, ti-2, ti-1 и ti - содержимое переменных pkt.org, pkt.rec, pkt.xmt и peer.rec, соответственно. Смещение часов j, rtt=d и дисперсия e ЭВМ по отношению к партнеру равны:
d = (ti - ti-3) - (ti-1 - ti - 2),
j = ((ti - 2 - ti-3) + ( ti-1 - ti))/2,
e = (1 j (ti - ti-3),
где, как и прежде, j = ntp.maxskew/ntp.maxage. e представляет собой максимальную ошибку или дисперсию, связанную с ошибкой измерения на стороне ЭВМ, а также накопление ошибок из-за дрейфа локальных часов за время после посылки последнего сообщения, посланного партнером. Дисперсия корректируется процедурой фильтра часов (clock-filter).
Рассмотренный метод эквивалентен непрерывному стробированию, которое используется в некоторых телефонных сетях [bel86]. Преимуществом метода является полная независимость от порядка и времени прихода сообщений, а также допустимость потери некоторых пакетов. Очевидно, что достижимые точности зависят от статистических свойств каналов связи.
Тест 4 требует, чтобы вычисленная задержка лежала в допустимых пределах:
test4 d| < ntp.maxdisperse И e
Тест 5 используется, только если реализован механизм аутентификации. Он требует, чтобы либо аутентификация была явно блокирована, либо чтобы аутентификатор в точности соответствовал тому, что описано в процедуре дешифровки.
#ifdef (authentication implemented) /* Тест 5 */
test5
#endef
Тест 6 требует, чтобы часы партнера были синхронизованы, и время с момента последней коррекции было положительным и меньше чем ntp.maxage.
Тест 7 гарантирует, что ЭВМ не будет синхронизовано от партнера с большим кодом номера слоя.
Тест 8 требует, чтобы заголовок содержал соответствующие коды в полях pkt.rootdelay и pkt.rootdispersion.
| test6 2 and | /* Тест 6 */ |
{pkt.reftime ? pkt.xmt
| test7 | /* Тест 7 */ |
{pkt.stratum
| test8 | /* Тест 8 */ |
{pkt.rootdispersion
С точки зрения последующей обработки пакеты содержат корректные данные, если успешно проходят тесты 1-4 (test1 & test2 & test3 & test4 = 1), вне зависимости от результатов других тестов. Только пакеты с корректными данными могут использоваться для вычисления смещения (offset), задержки (delay) и дисперсии. Пакеты имеют корректные заголовки, если успешно проходят тесты 5-8 (test5 & test6 & test7 & test8 = 1), вне зависимости от результатов остальных тестов.
Только пакеты с корректными заголовками могут использоваться для определения того, может ли партнер быть выбран в качестве источника синхронизации. Заметим, что тесты 1-2 не используются в широковещательном режиме.
Процедура "часовой фильтр" вызывается для вычисления задержки (peer.delay), смещения (peer.offset) и дисперсии (peer.dispersion) для партнера. Спецификация алгоритма часового фильтра не является составной частью протокола NTP. По этой причине описания, приводимые ниже, следует рассматривать как рекомендательные.
if (not valid header) exit;
| peer.leap < pkt.leap; | /* Копирование переменных пакета */ |
peer.stratum ;
peer.precision ;
peer.rootdelay ;
peer.rootdispersion ;
peer.refid ;
peer.reftime ;
| if (valid data) call clock-filter(q, d, e); | /* обработка данных */ |
end packet procedure;
Процедура коррекции показаний часов
Процедура коррекции показания часов вызывается процедурой приема, когда процедура фильтрации определила корректные значения смещения задержки и дисперсии для данного партнера.
begin clock-update procedure
| call clock-select; | /* Выбор базовых часов */ |
if (sys.peer ? peer) exit;
Может так случиться, что локальные часы оказались сброшены. В этом случае вызывается процедура очистки (clear procedure) для каждого из партнеров, чтобы возвратить в исходное состояние фильтр часов, период рассылки и, если необходимо, осуществить выбор нового источника синхронизации.
Процедура расстояния вычисляет базовую (root) задержку d, базовую дисперсию e и базовое расстояние синхронизации l. ЭВМ не будет синхронизовать выбранного партнера, если расстояние больше чем ntp.maxdistance.
| l andistance(peer); | /* обновление системных переменных */ |
if (l ? ntp.maxdistance) exit;
sys.leap
sys.stratum
sys.refid
call local-clock;
| if (local clock reset) begin | /* если сброс, очистить системные переменные */ |
sys.leap 2;
for (all peers) call clear;
endif
else begin
| sys.peer | /* если нет, то подстроить локальные часы */ |
sys.rootdelay d;
sys.rootdispersion e + max (ex
+ |t|, ntp.mindisperse);
endif
sys.reftime
end clock-update procedure;
В некоторых конфигурациях системы прецизионный источник временной информации доступен в виде последовательности синхронизующих импульсов, следующих с периодом в одну секунду. Обычно это является дополнением к базовому источнику времязадающей информации, такому как радио-часы или даже сам протокол NTP, для того чтобы обеспечить подсчет секунд, минут, часов и дней. В этих конфигурациях системные переменные устанавливаются с учетом источника, от которого поступают такие импульсы. Для конфигураций, которые поддерживают первичные эталонные источники, такие как радио-часы или калиброванные атомные часы код слоя устанавливается равным 1, поскольку именно он является действительным источником синхронизации.
Спецификация алгоритмов выбора часов и работы локальных часов не являются составной частью NTP. По этой причине описания этих алгоритмов, представленные ниже, следует рассматривать лишь как рекомендации.
Работа первичных часов (primary-clock procedure)
Когда ЭВМ связана с первичным эталоном времени, таким как радио-часы, удобно ввести информацию об этих часах в базу данных, как если бы это был обычный партнер. В процедуре первичных часов часы запрашиваются раз в минуту или около того, полученный же временной код используется для корректировки показаний местных часов. Когда обнуляется peer.timer для первичного партнера, процедура передачи не вызывается, а посылается запрос радио-часам с использованием ASCII-последовательности, предусмотренной для этого случая. Когда получен корректный временной код от радио-часов, он преобразуется в формат временной метки NTP и корректируются соответствующие переменные партнера. Величина peer.leap устанавливается в зависимости от состояния бита оповещения временного кода, если таковой имеется, или вручную оператором. Значение для peer.peeraddr, которое становится равно sys.refid, когда вызывается процедура корректировки показаний часов, делается равным ASCII-строке, описывающей часы.
begin primary-clock-update procedure
|
peer.leap | /* Копирование переменных */ |
peer.peeraddr
peer.rec
peer.reach
| call clock-filter({sys.clock - peer.rec, 0, 1 | /* образец процесса */ |
| call clockupdate; | /* коррекция локальных часов */ |
end primary-clock-update procedure;
Процедуры инициализации
Процедура инициализации вызывается при перезагрузке системы или при повторном запуске демона NTP. Состояние локальных часов при загрузке предполагается неопределенным; однако, некоторые виды оборудования обеспечивают доступ к локальным часам, как в ходе загрузки, так и сразу после нее. Переменная точности определяется внутренней архитектурой оборудования локальных часов. Аутентификационные переменные используются лишь при реализации механизма аутентификации. Значения этих переменных определяются процедурами, выходящими за рамки протокола NTP.
begin initialization procedure
#ifdef (authentication implemented)
sys.keys
#endef;
| sys.leap 2; | /* копирование переменных */ |
sys.stratum
sys.precision
sys.rootdelay
sys.rootdispersion
sys.refid
sys.reftime
sys.clock
sys.peer
sys.poll
| for (all configured peers) | /* создание конфигурированных ассоциаций */ |
call initialization-instantiation procedure;
end initialization procedure;
Процедура initialization-instantiation
Эта процедура является аппаратно-зависимой и служит, среди прочего, для формирования ассоциации. Адреса и режимы работы партнеров определяются в процессе чтения при перезагрузке или в результате обработки команд оператора. В случае привлечения механизма аутентификации только аутентифицированный партнер может стать источником синхронизации.
begin initialization-instantiation procedure
peer.config
#ifdef (authentication implemented)
peer.authenable
peer.authentic
peer.hostkeyid
peer.peerkeyid
#endef;
|
peer.peeraddr | /* копирование переменных */ |
peer.peerport
peer.hostaddr
peer.hostport
peer.mode
peer.peerpoll
peer.timer
peer.delay
peer.offset
| call clear; | /* инициализация ассоциации */ |
end initialization-instantiation procedure;
Процедура receive-instantiation
Процедура receive- instantiation вызывается процедурой приема, когда обнаруживается новый партнер. Она инициализирует переменные партнера и формирует ассоциацию. Если сообщение получено от партнера, работающего в режиме клиента (3), ЭВМ переводится в режим сервера (4); в противном случае, она устанавливается в симметрично пассивный режим (2).
begin receive-instantiation procedure
#ifdef (authentication implemented)
peer.authenable
peer.authentic
peer.hostkeyid
peer.peerkeyid
#endef
|
peer.config | /* Копирование переменных */ |
peer.peeraddr
peer.peerport
peer.hostaddr
peer.hostport
| if (pkt.mode = 3) | /* Определение режима */ |
peer.mode
else
peer.mode
peer.peerpoll
peer.timer
peer.delay
peer.offset
| call clear; | /* инициализация ассоциации */ |
end receive-instantiation procedure;
Процедура primary clock-instantiation
Эта процедура вызывается из процедуры инициализации для того, чтобы установить переменные состояния для первичных часов. Значение peer.precision определяется из спецификации радио-часов и аппаратного интерфейса. Значение peer.rootdispersion номинально равно удесятеренной максимальной ошибке радио-часов, например, 10 мсек для WWVB или радио-часов goes и 100 мсек для менее точных радио-часов WWV.
begin clock-instantiation procedure
|
peer.config | /* копирование переменных */ |
peer.peeraddr
peer.peerport
peer.hostaddr
peer.hostport
peer.leap 2;
peer.mode
peer.stratum
peer.peerpoll
peer.precision
peer.rootdelay
peer.rootdispersion
peer.refid
peer.reftime
peer.timer
peer.delay
peer.offset
| call clear; | /* инициализация ассоциации */ |
end clock-instantiation procedure;
В некоторых конфигурациях, включающих в себя атомные часы или приемники LORAN-C, первичный эталон может выдавать только секундные импульсы и не предоставлять полного временного кода (числа секунд и пр.). В этих конфигурациях нумерация секунд может быть получена из других источников, таких как радио-часы или даже другие NTP-партнеры.
В этих конфигурациях переменные первичных часов должны отражать особенности первичного эталона, а не источника нумерации секунд. Однако если источник нумерации секунд отказал или работает некорректно, актуализация локальных часов от первичного эталона должна быть заблокирована.
Процедура очистки
Процедура очистки вызывается, когда произошло событие, которое значительно изменило достижимость или вызвало поломку локальных часов.
begin clear procedure
|
peer.org | /* пометка неопределенных временных меток */ |
peer.rec
peer.xmt
| peer.reach | /* сброс переменных состояния */ |
| peer.filter | /* все ступени */ |
peer.valid
peer.dispersion
| {peer.hostpoll | /* первичная установка периода рассылки */ |
call poll-update;
| call clock-select; | /* Выбор эталонных часов */ |
end clear procedure;
Процедура запроса-коррекции (poll-update)
Процедура запросов-коррекции вызывается, когда происходит событие, которое может вызвать изменение периода запросов (рассылки) или таймера партнера. Она проверяет значения периода запросов ЭВМ (peer.hostpoll) и партнера (peer.peerpoll), а также устанавливает их в заданных пределах.
begin poll-update procedure
|
temp | /* определение периода запросов ЭВМ */ |
if (peer = sys.peer)
temp
else
temp
peer.hostpoll
temp
Если интервал запросов (рассылок) не изменился, а таймер партнера на нуле, то таймер просто сбрасывается в начальное состояние. Если интервал запросов изменен, и новое значение таймера больше текущего значения, никаких дополнительных действий не требуется; в противном случае величина выдержки таймера партнера должна быть уменьшена. Когда время выдержки таймера партнера уменьшается, важно исключить тенденцию синхронизации обмена между партнерами. Благоразумной предосторожностью является рэндмизация первой передачи после уменьшения выдержки таймера.
| if (peer.timer = 0) | /* сброс таймера партнера */ |
peer.timer
else if (peer.timer >temp)
peer.timer
end poll-update procedure;
Процедура расстояния синхронизации (synchronization distance)
Процедура расстояния вычисляет расстояние синхронизации на основе переменных партнеров.
begin distance(peer) procedure;
d
e f (sys.clock - peer.update)};
le + |d|/2;
end distance procedure;
Заметим, что, в то время как d может быть в некоторых случаях отрицательной, e и l всегда положительны.
Замечания о контроле доступа
Конструкция NTP устроена так, что случайная или намеренная модификация данных временного сервера не должна привести к серьезным ошибкам синхронизации. Однако успех этого подхода зависит от дополнительных временных серверов и альтернативных сетевых маршрутов, а также от предположения, что искажения не охватывают большинство временных серверов одновременно. В принципе уязвимость субсети может быть улучшена разумным выбором временных серверов. Механизм аутентификации также позволяет повысить надежность синхронизации. Следует, правда, принимать во внимание, что шифрование/дешифрование данных заметно ухудшает точность синхронизации.
Если требуется более надежная модель, система может базироваться на списке доступа, в который включаются 32-битовый IP-адрес, 32-битовая маска и 3-битовый код режима работы. Если логическое И адреса эталона (pkt.peeraddr) и маски на входе ЭВМ соответствуют соответствующим адресу и режиму (pkt.mode), доступ разрешается, в противном случае отправителю запроса присылается ICMP-сообщение об ошибке. Список управления доступом служит фильтром, определяющим, какой из партнеров может сформировать ассоциацию.
Алгоритмы фильтрации и селекции
Наиболее важным фактором, влияющим на точность и надежность синхронизации, является набор алгоритмов, используемых для уменьшения статистических ошибок и искажений при сбоях в различных компонентах субсети. Алгоритмы, описанные в этой статье, не являются частью стандарта NTP, по этой причине допускается использование любых других алгоритмов.
Для того чтобы NTP алгоритмы фильтрации и отбора работали эффективно, полезно иметь меру вариации для каждого из партнеров. Принятая мера вариации базируется на разностях первого порядка, которые легко вычислить.Существует две меры, одна называемая дисперсией фильтра es, и другая дисперсия выбора (select dispersion) ez. Обе меры вычисляются как взвешенные суммы смещений из списка, сформированного на основе расстояний синхронизации. Если qi (0Ј i < n) смещение i-ой записи, тогда разность eij i-ой записи по отношению к j-ой записи определяется как |qi - q j|. Дисперсия относительно j-ой записи определяется как ej =
Коды источников временного эталона
Таблица 4.4.15.6. Коды источников временного эталона
|
Код |
Функция |
0 |
Не специфицирован или неизвестен |
1 |
Калиброванные атомные часы (напр., hp 5061) |
2 |
vlf (диапазон 4) или НЧ (диапазон 5) радио (напр., omega, wwvb) |
3 |
ВЧ (диапазон 7) радио (напр., chu, msf, wwv/h) |
4 |
УВЧ (диапазон 9) спутник (напр., goes, gps) |
5 |
Локальная сеть (напр., dcn, tsp, dts) |
6 |
UDP/NTP |
7 |
UDP/time |
8 |
eyeball-and-wristwatch |
9 |
Телефонный модем (напр., nist) |
10-63 |
Зарезервировано на будущее |
Системный счетчик событий - четырех битовое целое число, обозначающее число событий, происшедших с момента последнего получения статусного слова системы. Счетчик обнуляется, когда присылается в статусном поле отклика и остается неизменным после достижения значения 15.
Код системного события - четырехбитовое число, идентифицирующее последнее системное событие, новое значение переписывает предыдущее. Коды событий перечислены в таблице 4.4.15.7.
Коды класса партнера
Таблица 4.2.3.1 Коды класса партнера
|
Код класса |
Описание |
1 |
Зарезервировано |
2 |
Сервер внешнего порта PPP NetBIOS |
3 |
Зарезервировано |
4 |
Сервер локального доступа PPP NetBIOS |
5 |
Зарезервировано |
6 |
Мост PPP NetBIOS |
7 |
Зарезервировано |
8 |
Терминальная система PPP |
Протокол WINS
Протокол WINS разработан компанией MicroSoft для операционной среды Windows и предназначен для расширения возможностей NetBIOS.
WINS-запросы обычно транспортируются в UDP-дейтограммах. При этом используется порт отправителя=137. В поле данных размешается 2-октетное поле идентификатора, позволяющего связать запрос с откликом. Далее следует 2 байта флагов, в случае запроса туда записывается 0. За ним размещается два октета, содержащие число вопросов, 2 октета числа ответов и еще 4 нулевых октетов. Завершается кадр запроса двумя октетами поля типа (00 21 -> статус узла NetBIOS) и полем класса (для Интернет 00 01 -> (IN,1)). Такие запросы позволяют получить дополнительные данные (имя узла, его MAC-адрес, NetBIOS-имя, имя группы) об ЭВМ с заданным IP-адресом. Причем эта ЭВМ может находиться где угодно в Интернет, но непременно работать в OS Windows. Формат поля данных UDP-дейтограммы запроса показан на Рисунок 1.
Коды ошибки
Таблица 4.4.15.12. Коды ошибки
Код ошибки |
Значение |
0 |
Не специфицировано |
1 |
Неудачная аутентификация |
2 |
Неверный формат или длина сообщения |
3 |
Неверный код операции |
4 |
Неизвестный идентификатор ассоциации |
5 |
Неизвестное имя переменной |
6 |
Неверное значение переменной |
7 |
Административно запрещено |
8-255 |
Зарезервировано на будущее |
Команды
Команды состоят из заголовка и опционного поля данных. Если поле данных присутствует, оно включает в себя список идентификаторов и, возможно, их значений.
[=],[=],...
где представляет собой имя переменной системы или партнера в форме ASCII-последовательности, а является десятичным или шестнадцатеричным числом, или строкой, соответствующей синтаксису языка C. Для большей читаемости допускается применение пробелов (Whitespace). IP-адреса представляются в формате [n.n.n.n], где n - десятичное число. Скобки являются опционными.
Команды интерпретируются следующим образом:
Чтение статуса (1). Поле данных команды пусто или содержит список идентификаторов, разделенных запятыми. Команда работает по-разному в зависимости от значения идентификатора. Если идентификатор не равен нулю, отклик содержит идентификатор партнера и статусное слово. Если идентификатор ассоциации равен нулю, отклик содержит системный идентификатор (0) и статусное слово, в то время как поле данных содержит список пар двоичных кодов:
,
по одному на каждую, определенную в данный момент ассоциацию.
Чтение переменных (2). Поле данных команды пусто или содержит список идентификаторов, разделенных запятыми. Если идентификатор ассоциации не равен нулю, отклик включает в себя идентификатор запрашиваемого партнера и его статусное слово, в то время как в поле данных записывается список переменных партнера и их значения. Если идентификатор ассоциации равен нулю, поле данных содержит список системных переменных и их значения. Если партнер выбран в качестве источника синхронизации, отклик включает в себя идентификатор партнера и его статусное слово.
Запись переменных (3). Поле данных команды содержит список присвоений, описанный выше.
Отклик идентичен отклику на команду чтения переменных.
Чтение переменных часов (4). Поле данных команды пусто или содержит список идентификаторов, разделенных запятыми. Идентификатор ассоциации выбирает переменные системных часов или партнера точно также, как в случае команды чтения переменных. Отклик включает в себя запрошенные идентификатор часов и статусное слово, а поле данных несет в себе список переменных часов и их значений, включая последний временной код, полученный от часов.
Запись переменных часов (5). Поле данных команды содержит список присвоений, как это описано выше. Отклик имеет формат, как в случае команду чтения переменных часов.
Установка адреса/порта Trap (6). Идентификатор ассоциации команды, статус и поле данных игнорируются. Адрес и номер порта для последующих TRAP-сообщений берутся из самого управляющего сообщения. Исходное значение счетчика TRAP для сообщений откликов заимствуется из поля номера по порядку. Идентификатор ассоциации, статус и поле данных в отклике несущественны.
Отклик на TRAP (7). Это сообщение посылается, когда происходит событие (exception) в систему, у партнера или для данных часов. Код команды равен 7, а бит R=1. Содержимое trap-счетчика увеличивается на 1 для каждого сообщения данного типа. Поле номер по порядку сообщения равно содержимому этого счетчика. При посылке сообщения TRAP используется IP-адрес и номер порта, заданные командой установки адреса и порта TRAP. В случае системного TRAP идентификатор ассоциации устанавливается равным нулю, а поле статус содержит статусное слово системы. В случае TRAP партнера поле идентификатора ассоциации соответствует партнеру, а поле статус несет в себе его статусное слово. В поле данных опционно может быть включено любое символьное сообщение (ASCII).
Коды откликов
Таблица 4.2.1.3.2 Коды откликов
|
Код типа отклика |
Описание |
3333 |
Отклик |
|
7777 |
Соединение для протокола Burst Mode |
|
9999 |
Запрос обрабатывается |
Сервер отвечает на большую часть запросов, помещая код 3333 в поле типа отклика. Если запрос клиента помещен в очередь, а клиент по таймауту выдал еще один запрос, ему присылается отклик типа “Запрос обрабатывается”. Станция клиента при этом сбросит таймер в исходное состояние, добавит 1 к счетчику попыток и продолжит ожидание. По умолчанию запрос можно повторить 20 раз. Поле код завершения указывает на характер завершения выполнения запроса клиента. Код нуль говорит об успешном завершении, любое другое число - об ошибке. Поле состояние канала содержит флаги, характеризующие статус канала, клиенты NetWare должны проверять код этого поля во всех пакетах, приходящих от сервера. Кроме заголовка (запросов и откликов) каждое NCP-сообщение должно содержать в себе код NCP-процедуры, характеризующий запрашиваемую услугу. Часто помимо кода процедуры необходимо указать и ее субкод. Перечень кодов процедур и их функций приведен в приложении.
Помимо стандартных пакетов в среде Novell используются несколько вспомогательных видов пакетов. Это пакеты “сторожевая собака” (Watchdog), сериализации (serialization) и сообщения. Пакеты “сторожевая собака” после IPX-заголовка имеет поля номера канала и сигнатура. Поле номера канала отмечает канал станции, присвоенный ей при регистрации. Поле сигнатура содержит код 0x3F. Если отклика от рабочей станции нет, то сервер передает с интервалом 59 сек 10 аналогичных “собачих” пакетов. Если отклика добиться не удастся, связь со станцией будет разорвана. Период и число таких запросов администратор может изменять в широких пределах.
Так как система NetWare продается для каждого сервера отдельно, чтобы контролировать случаи нелегальной загрузки, по сети рассылаются широковещательные пакеты сериализации. Цель такой рассылки - проверка наличия в сети нескольких копий одного и того же программного обеспечения. Пакеты сериализации содержат 36 байт, включая IPX-заголовок, и передаются раз в 66 сек. Эти пакеты помимо IPX-заголовка включают в себя только поле данных (6 байт), где содержится информация о серийном номере программного продукта. Пакеты сериализации всегда посылаются на вход соединителя (socket) с номером 0x0457. При обнаружении нелегальной копии всем пользователям рассылается уведомление “Copyright violation”.
Пользователи NetWare могут передавать сообщения рабочим станциям, группам и другим пользователям. Для каждой станции NetWare резервирует буфер для сообщений. Консоль отображает принятое сообщение немедленно, буфер же сохраняет сообщение и может уведомлять о нем пользователя. Для передачи сообщений используется команда SEND.
Коды системных событий
Таблица 4.4.15.7. Коды системных событий
|
Код |
Функция |
0 |
Не специфицировано |
1 |
Рестарт системы |
2 |
Системный или аппаратный сбой |
3 |
Новое статусное слово системы (изменение битов добавления или синхронизации) |
4 |
Новый источник синхронизации или слой (изменение sys.peer или sys.stratum) |
5 |
Сброс системных часов (корректирующая добавка превысила clock.max) |
6 |
Некорректное системное время или дата |
7 |
system clock exception |
8-15 |
Зарезервировано на будущее |
Статусное слово партнера
Статусное слово партнера возвращается в статусном поле отклика на команду чтения статуса, а также чтения или записи переменных. Это слово появляется в списке идентификаторов ассоциации и статусных слов, присылаемых в ответ на команду чтения статуса с нулевым идентификатором ассоциации. Формат статусного слова партнера содержит следующие поля (Рисунок 4.4.15.3)
Коды события партнера
Таблица 4.4.15.10. Коды события партнера
>
|
Значение кода |
Функция |
0 |
Не специфицировано |
1 |
IP-ошибка партнера |
2 |
Ошибка аутентификации партнера (бит peer.authentic был равен 1, а теперь =0) |
3 |
Партнер не достижим (peer.reach стал равен нулю) |
4 |
Партнер достижим (peer.reach стал не равен нулю) |
5 |
Проблема с часами партнера |
6-15 |
Зарезервировано на будущее |
Слово состояния часов
Существует два способа подключить эталонные часы к NTP-серверу, как специальный прибор, поддерживаемый операционной системой или как партнера, управляемого NTP. Как и в случае команды чтения статуса идентификатор ассоциации определяет, часы какого из партнеров имеются в виду. При нулевом идентификаторе речь идет о системных часах. Протокол поддерживает только одни системные часы, число часов-партнеров практически не ограничено. Статусное слово часов системы или партнера записывается в поле статуса отклика на команды чтения или записи переменных, характеризующих часы. Это слово может рассматриваться как расширение системного статусного слова или статусного слова партнера. Формат слова описан ниже (См. также Рисунок 4.4.15.3).
Состояние часов - 8-битовое число, характеризующее текущее состояние часов. Допустимые значения этого числа и их смысл представлены в таблице 4.4.15.11.
Коды состояния часов
Таблица 4.4.15.11. Коды состояния часов
|
Код |
Функция |
0 |
Работа часов в пределах нормы |
1 |
Таймаут ответа |
2 |
Плохой формат ответа |
3 |
Сбой оборудования или программы |
4 |
Потеря при передаче |
5 |
Неверный формат или значение даты |
6 |
Неверный формат или значение времени |
7-255 |
Зарезервировано на будущее |
Код события для часов - 8-битовый код, идентифицирующий последнее событие для данных часов (exception). Новое значение переписывает предыдущее значение кода. Когда значение кода становится ненулевым для поля статуса радио-часов, этот код копируется в статусное поле кода события и считается, что произошло событие для системных часов или часов партнера.
Слово состояния ошибки
Статусное слово ошибки присылается в поле статуса отклика, если обнаружена ошибка в формате сообщения или в его содержимом. Его присутствие указывается равенствами E (error) и R (response) битов 1. Коды ошибки и их значения собраны в таблице 4.4.15.12.
Коды состояния партнера
Таблица 4.4.15.8. Коды состояния партнера
|
Значение кода |
Функция |
|
0 |
Сконфигурирован (peer.config) |
|
1 |
Разрешена аутентификация (peer.authenable) |
|
2 |
Аутентификация успешна (peer.authentic) |
|
3 |
Партнер доступен (peer.reach) |
|
4 |
Зарезервировано на будущее |
Выбор партнера (Sel) - 3-битный код, говорящий о состоянии партнера, определенного в результате процедуры выбора часов. Значения кодов представлены в таблице 4.4.15.9.
Коды типа компонентов
Таблица 4.2.1.5.1. Коды типа компонентов
|
Код компонента |
Тип компонента |
Описание |
0 |
IPX/SPX |
IPX/SPX-процесс или модуль на выделенном файл-сервере, маршрутизаторе или у клиента. |
1 |
Драйвер маршрутизатора |
Процесс драйвера маршрутизации. |
2 |
Драйвер локальной сети |
Процесс драйвера интерфейса локальной сети на файл-сервере или маршрутизаторе. |
3 |
Оболочка |
Модуль-эмулятор или оболочка DOS на рабочей станции (netx.com) |
4 |
vap |
Модуль-эмулятор или оболочка DOS на сервере netware 2.x или внешнем маршрутизаторе для поддержания VAP. |
5 |
Маршрутизатор |
Маршрутизирующий компонент внешнего порта сети (gateway) |
6 |
Файловый сервер/маршрутизатор |
Маршрутизирующий компонент файл-сервера (внутренний маршрутизатор или мост). |
7 |
Невыделенный IPX/SPX |
IPX/SPX-процесс на невыделенном файл-сервере netware 2.x, внешнем порте сети или локальной сети версий 3.x. |
Далее следует поле числа локальных сетей, характеризующее количество сетей, обменивающееся данными с данным компонентом. Для каждой из сетей указывается ее тип, а также адрес сети и узла. Поле типа сети содержит код типа (таблица 4.2.1.5.2).
Коды типа сети
Таблица 4.2.1.5.2 Коды типа сети
|
Код типа сети |
Компонент |
0 |
Интерфейс локальной сети |
1 |
Невыделенный файл-сервер |
2 |
Перенаправленная удаленная линия |
Поле адреса сети имеет 4 байта, а поле адреса узла 6 байт, перенаправленные удаленные линии имеют адрес узла 0x00-00-00-00-00-00. Внутренние сети IPX версий 3.x и 4.x имеют адрес узла 0x00-00-00-00-00-01.
Коды выбора партнера
Таблица 4.4.15.9. Коды выбора партнера
|
Значение кода |
Функция |
0 |
Отклонен |
1 |
Проверка соответствия прошла успешно (тесты 1 - 8) |
2 |
Прошел проверки корректности (алгоритм пересечения) |
3 |
Прошел проверки, как кандидат |
4 |
Проверка ресурсов прошла успешно (алгоритм кластеризации) |
5 |
Текущий источник синхронизации; превышено максимальное расстояние (если используются предельные проверки) |
6 |
Текущий источник синхронизации; максимальное расстояние в пределах нормы |
7 |
Зарезервировано на будущее |
Счетчик событий партнера - 4-битовое число событий (exception) партнера, которые имели место со времени последнего получения статусного слова в рамках отклика или сообщения TRAP. Счетчик сбрасывается при занесении кода в поле статуса отклика, и перестает изменяться при достижении значения 15.
Код события партнера - 4-битовое целое число, идентифицирующее последнее событие партнера. Новое значение переписывает предыдущее. Значения кодов представлены в таблице 4.4.15.10.
команд службы каталогов приведена в приложении (
Таблица команд службы каталогов приведена в приложении (10.5) .
В netware имеется развитая собственная система сетевой диагностики, которая позволяет выяснить реальную конфигурацию сети (возможно, что-то не включено или уже сломалось), ее загруженность или частоту ошибок (diagnostic responder). Узлы сети с загруженной программой diagnostic responder должны откликаться на диагностические пакеты, адресованные им или разосланные широковещательно. Наличие отклика говорит о доступности данного сетевого объекта, а его содержимое может нести в себе информацию о конфигурации (наличие IPX/SPX, драйвера локальной сети, программы маршрутизатора или файлового сервера).
операций и субопераций NCP
10.4 Таблица операций и субопераций NCP
|
Код операции |
Код субоперации |
Описание |
| 23 1 | 50 | Get Current Account Status |
| 23 1 | 51 | Submit Account Change |
| 23 1 | 52 | Submit Account Hold |
| 23 1 | 53 | Submit Account Note |
|
Обслуживание файловой системы Apple |
||
| 35 | 01 | AFP Create Directory |
| 35 | 02 | AFP Create File |
| 35 | 03 | AFP Delete |
| 35 | 04 | AFP Get Entry ID from Name |
| 35 | 05 | AFP Get File Information |
| 35 | 06 | AFP Get Entry ID from NetWare Handle |
| 35 | 07 | AFP Rename |
| 35 | 08 | AFP Get Open File Fork |
| 35 | 09 | AFP Set File Information |
| 35 | 10 | AFP Scan File Information |
| 35 | 11 | AFP 2.0 Alloc Temporary Directory Handle |
| 35 | 12 | AFP Get Entry ID from Name Path |
| 35 | 13 | AFP 2.0 Create Directory |
| 35 | 14 | AFP 2.0 Create file |
| 35 | 16 | AFP 2.0 Set File Information |
| 35 | 17 | AFP 2.0Scan file Information |
| 35 | 18 | AFP Get DOS Name from Entry ID |
| 35 | 19 | AFP Get Macintosh Info on Deleted File |
|
Аудиторские услуги |
||
| 88 | 01 | Query Volume Audit Status |
| 88 | 02 | Add Audit Property |
| 88 | 03 | Add Audit Access |
| 88 | 04 | Change Audit Password |
| 88 | 05 | Check Auditor Access |
| 88 | 06 | Delete Audit Property |
| 88 | 07 | Disable Volume Auditing |
| 88 | 08 | Enable Volume Auditing |
| 88 | 09 | Is User Audited |
| 88 | 10 | Read Audit Bit Map |
| 88 | 11 | Read Audit Config Header |
| 88 | 12 | Read Auditing File |
| 88 | 13 | Remove Auditor Access |
| 88 | 14 | Reset Audit File |
| 88 | 15 | Reset History File |
| 88 | 16 | Write Audit Bit Map |
| 88 | 17 | Write Audit Config Header |
|
Работа с базой данных Bindery и операции доступа |
||
| 23 | 50 | Create Bindery Object |
| 23 | 51 | Delete Bindery Object |
| 23 | 52 | Rename Object |
| 23 | 53 | Get Bindery Object ID |
| 23 | 54 | Get Bindery Object in Set |
| 23 | 55 | Scan Bindery Object |
| 23 | 56 | Change Bindery Object Security |
| 23 | 57 | Create Property |
| 23 | 58 | Delete Property |
| 23 | 59 | Change Bindery Security |
| 23 | 60 | Scan Property |
| 23 | 61 | Read Property Value |
| 23 | 62 | Write Property Value |
| 23 | 63 | Verify Bindery Object Password |
| 23 | 64 | Change Bindery Object Password |
| 23 | 65 | Add Bindery Object to Set |
| 23 | 66 | Delete Bindery Object from Set |
| 23 | 67 | Is Bindery Object in Set? |
| 23 | 68 | Close Bindery |
| 23 | 69 | Open Bindery |
| 23 | 70 | Get Bindery Access Level |
| 23 | 71 | Scan Bindery Object Trustee Paths |
| 23 | 72 | Get Bindery Object Access Level |
| 23 | 73 | Is Calling Station a Manager? |
| 23 | 74 | Keyed Verify Password |
| 23 | 75 | Keyed Change Password |
| 23 | 76 | List Relations of an Object |
|
Обслуживание каналов |
||
| 19 | - | Get Station Number |
| 23 | 20 | Login Object |
| 23 | 23 | Get Login Key |
| 23 | 24 | Keyed Object Login |
| 23 | 26 | Get Internet Address |
| 23 | 27 | Get Object Connection List |
| 23 | 28 | Get Station’s Logged Information |
| 23 | 29 | Change Connection State |
| 23 | 30 | Watchdog Interval |
| 23 | 31 | Get Connection List from Object |
| 24 | - | End of Job |
| 25 | - | Logout |
| 33 | - | Negotiate Buffer Size |
| 88 | 01 | Clear Connection Number List |
| 97 | - | Get Big Packet NCP Max Packet Size |
|
Работа с расширенными атрибутами |
||
| 86 | 01 | Close Extended Attribute Handle |
| 86 | 02 | Write Extended Attribute |
| 86 | 03 | Read Extended Attribute |
| 86 | 04 | Enumerate Extended Attribute |
| 86 | 05 | Duplicate Extended Attribute |
|
Работа с каталогами и файлами |
||
| 18 | - | Get Volume Info with Number |
| 22 | 00 | Set Directory Handle |
| 22 | 01 | Get Directory Path |
| 22 | 02 | Scan Directory Information |
| 22 | 04 | Modify Maximum Rights Mask |
| 22 | 05 | Get Volume Number |
| 22 | 06 | Get Volume Name |
| 22 | 10 | Create Directory |
| 22 | 11 | Delete Directory |
| 22 | 12 | Scan Directory for Trustee |
| 22 | 13 | Add Trustee to Directory |
| 22 | 14 | Delete Trustee from Directory |
| 22 | 15 | Rename Directory |
| 22 | 18 | Allocate Permanent Directory Handle |
| 22 | 19 | Allocate Temporary Directory Handle |
| 22 | 20 | Deallocate Directory Handle |
| 22 | 21 | Get Volume Info with Handle |
| 22 | 22 | Allocate Special Temporary Directory Handle |
| 22 | 23 | Map Directory Number to Path |
| 22 | 25 | Set Directory Information |
| 22 | 26 | Get Path Name of a Volume-Directory Number Pair |
| 22 | 29 | Get Effective Directory Rights |
| 22 | 30 | Scan a Directory |
| 22 | 31 | Get Directory Entry |
| 22 | 32 | Scan Volume’s User Disk Restrictions |
| 22 | 33 | Add User Disk Space Restriction |
| 22 | 34 | Remove User Disk Space Restrictions |
| 22 | 35 | Get Directory Disk Space Restriction |
| 22 | 36 | Set Directory Disk Space Restrictions |
| 22 | 37 | Set Directory Entry Information |
| 22 | 38 | Scan File or Directory for Extended Trustee |
| 22 | 39 | Add Extended Trustee to Directory or File |
| 22 | 40 | Scan Directory Disk Space |
| 22 | 41 | Get Object Disk Usage and Restrictions |
| 22 | 42 | Get Effective Rights for Directory Entry |
| 22 | 43 | Remove Extended Trustee to Directory or File |
| 22 | 44 | Get Volume and Purge Information |
| 22 | 45 | Get Directory Information |
| 22 | 46 | Rename or Move |
| 22 | 48 | Get Name Space Directory Entry |
| 22 | 49 | Open Data Stream |
| 22 | 50 | Get Object Effective Rights for Directory Entry |
| 22 | 51 | Get Extended Volume Information |
| 23 | 15 | Scan File Information |
| 23 | 16 | Set File Information |
| 23 | 26 | Purge All Erased Files |
| 61 | - | Commit File |
| 62 | - | File Search Initialize |
| 63 | - | File Search Continue |
| 64 | - | Search for a File |
| 66 | - | Close File |
| 67 | - | Create File |
| 68 | - | Erase File |
| 69 | - | Rename File |
| 70 | - | Set File Attributes |
| 71 | - | Get Current Size of File |
| 72 | - | Read from a File |
| 73 | - | Write to a File |
| 74 | - | Copy from One File to Another |
| 75 | - | Set File Time Date Stamp |
| 78 | - | Allow Task to Access File |
| 79 | - | Set File Extended Attributes |
| 84 | - | Open/Create File |
| 85 | - | Get Sparse File Data Block Bit Map |
| 87 | 01 | Open/Create File or Subdirectory |
| 87 | 03 | Search for a File or Subdirectory |
| 87 | 04 | Rename or Move a File or Subdirectory |
| 87 | 05 | Scan File or Directory for Trustee |
| 87 | 08 | Delete a File or Subdirectory |
| 87 | 09 | Set Short Directory Handle |
| 87 | 10 | Add Trustee Set to File or Subdirectory |
| 87 | 11 | Delete Trustee Set from File or Subdirectory |
| 87 | 12 | Allocate Short Directory Handle |
| 87 | 17 | Recover Salvageable File |
| 87 | 18 | Purge Salvageable File |
| 87 | 19 | Get Name Space Information |
| 87 | 20 | Search for a File or Subdirectory Set |
| 87 | 21 | Get Path String from Short Directory Handle |
| 87 | 22 | Generate Directory Base and Volume Number |
| 87 | 23 | Query Name Space Information Format |
| 87 | 24 | Get Name Space Loaded List from Volume Number |
| 87 | 25 | Set Name Space Information |
| 87 | 26 | Get Huge Name Space Information |
| 87 | 27 | Set Huge Name Space Information |
| 87 | 28 | Get Full Path String |
| 90 | 00 | Parse Tree |
| 90 | 150 | File Migration Request |
|
Среда файл-сервера |
||
| 15 | - | Locate a Resource |
| 16 | - | Deallocate a Resource |
| 20 | - | Get File Server Data and Time |
| 23 | 05 | Get File Server Login Status |
| 23 | 12 | Verify Serialization |
| 23 | 14 | Get Disk Utilization |
| 23 | 17 | Get File Server Information |
| 23 | 18 | Get Network Serial Number |
| 23 | 23 | Get File Server LAN I/O Statistics |
| 23 | 200 | Check Console Privileges |
| 23 | 201 | Get File Server Description String |
| 23 | 202 | Set File Server Date and Time |
| 23 | 203 | Disable File Server Login |
| 23 | 204 | Enable File Server Login |
| 23 | 207 | Disable Transaction Tracking |
| 23 | 208 | Enable Transaction Tracking |
| 23 | 211 | Down File Server |
| 23 | 212 | Get File System Statistics |
| 23 | 213 | Get Transaction Tracking Statistics |
| 23 | 214 | Read Disk Cache Statistics |
| 23 | 215 | Get Drive Mapping Table |
| 23 | 216 | Read Physical Disk Statistics |
| 23 | 217 | Get Disk Channel Statistics |
| 23 | 221 | Get Physical Record Locks by Connection and File |
| 23 | 227 | Get LAN Driver |
| 23 | 229 | Get Connection Usage Statistics |
| 23 | 230 | Get Object’s Remaining Disk Space |
| 23 | 232 | Get File Server Misc Information |
| 23 | 233 | Get Volume Information |
| 23 | 234 | Get Connection’s Task Information |
| 23 | 235 | Get Connection’s Open Files |
| 23 | 236 | Get Connections Using a File |
| 23 | 237 | Get Physical Record Locks by Connection and File |
| 23 | 238 | Get Physical Record Locks by File |
| 23 | 239 | Get Logical Records by Connection |
| 23 | 240 | Get Logical Record Information |
| 23 | 241 | Get Connection’s Semaphores |
| 23 | 242 | Get Semaphore Information |
| 23 | 245 | Get File Server Extended Misc Information |
| 23 | 246 | Get Volume Extended Miscellaneous Information |
| 23 | 252 | Release a Resource |
| 23 | 253 | Send Console Broadcast |
| 23 | 254 | Clear Connection Number |
|
Работа с сообщениями |
||
| 21 | 01 | Get Broadcast Message |
| 21 | 02 | Disable Broadcasts |
| 21 | 03 | Enable Broadcasts |
| 21 | 04 | Send Personal Message |
| 21 | 05 | Get Personal Message |
| 21 | 06 | Open Message Pipe |
| 21 | 07 | Close Message Pipe |
| 21 | 08 | Check Pipe Status |
| 21 | 09 | Broadcast to Console |
| 21 | 10 | Send Broadcast Message |
| 23 | 13 | Log Network Message |
|
Работа с принтером и очередями |
||
| 17 | 00 | Write to Spool File |
| 17 | 01 | Close Spool File |
| 17 | 02 | Set Spool File Flags |
| 17 | 03 | Spool a Disk File |
| 17 | 04 | Scan Spool File Queue |
| 17 | 05 | Delete Spool File |
| 17 | 06 | Get Printer Status |
| 17 | 09 | Create Spool File |
| 17 | 10 | Get Printer’s Queue |
| 23 | 137 | Get Queue Jobs from Form List |
|
Работа с очередями |
||
| 23 | 100 | Create Queue |
| 23 | 101 | Destroy Queue |
| 23 | 110 | Change Queue Job Position |
| 23 | 111 | Attach Queue Server to Queue |
| 23 | 112 | Detach Queue Server from Queue |
| 23 | 116 | Change to Client’s Rights |
| 23 | 117 | Restore Queue Server Rights |
| 23 | 119 | Set Queue Server Current Status |
| 23 | 121 | Create Queue Job and File |
| 23 | 122 | Read Queue Job Entry |
| 23 | 123 | Change Queue Job Entry |
| 23 | 124 | Service Queue Job |
| 23 | 125 | Read Queue Current Status |
| 23 | 126 | Set Queue Current Status |
| 23 | 127 | Close a File and Start Queue Job |
| 23 | 128 | Remove Job from Queue |
| 23 | 129 | Get Queue Job List |
| 23 | 130 | Change Jobiority |
| 23 | 131 | Finish Servicing Queue Job |
| 23 | 132 | Abort Servicing Queue Job |
| 23 | 134 | Read Queue Server Current Status |
| 23 | 135 | Get Queue Job File Size |
|
Синхронизация |
||
| 01 | - | File Set Lock |
| 02 | - | File Release Lock |
| 05 | - | Release File |
| 06 | - | Release File Set |
| 07 | - | Clear File |
| 08 | - | Clear File Set |
| 11 | - | Clear Logical Record |
| 12 | - | Release Logical Record |
| 13 | - | Release Logical Record Set |
| 14 | - | Clear Logical Record Set |
| 28 | - | Release Physical Record |
| 29 | - | Release Physical Record Set |
| 30 | - | Clear Physical Record |
| 31 | - | Clear Physical Record Set |
| 105 | - | Log File |
| 106 | - | Lock File Set |
| 107 | - | Log Logical Record |
| 108 | - | Lock Logical Record Set |
| 109 | - | Log Physical Record |
| 110 | - | Lock Physical Record Set |
| 111 | 00 | Open/Create Semaphore |
| 111 | 01 | Close Semaphore |
| 111 | 02 | Wait on Semaphore |
| 111 | 03 | Signal Semaphore |
| 111 | 04 | Examine Semaphore |
|
Отслеживание транзакций |
||
| 34 | 00 | TTS Is Available |
| 34 | 01 | TTS Begin Transaction |
| 34 | 02 | TTS End Transaction |
| 34 | 03 | TTS Abort Transaction |
| 34 | 04 | TTS Transaction Status |
| 34 | 05 | TTS Get Application Thresholds |
| 34 | 06 | TTS Set Application Thresholds |
| 34 | 07 | TTS Get Workstation Thresholds |
| 34 | 08 | TTS Set Workstation Thresholds |
| 34 | 09 | TTS Get Transaction Bits |
| 34 | 10 | TTS Set Transaction Bits |
|
Служба каталогов NetWare |
||
| 104 | 01 | Ping for NDS NCP |
| 104 | 02 | Send NDS Fragmented Request/Reply |
| 104 | 03 | Close NDS Fragment |
| 104 | 04 | Return Bindery Context |
| 104 | 05 | Monitor NDS Connection |
|
Работа со статистикой |
||
| 123 | 01 | Get Cache Information |
| 123 | 02 | Get File Server Information |
| 123 | 03 | NetWare File Systems Information |
| 123 | 04 | User Information |
| 123 | 05 | Packet Burst Information |
| 123 | 06 | IPX/SPX Information |
| 123 | 07 | Garbage Collection Information |
| 123 | 08 | CPU Information |
| 123 | 09 | Volume switch Information |
| 123 | 10 | Get NLM Loaded List |
| 123 | 11 | NLM Information |
| 123 | 12 | Get Directory Cache Information |
| 123 | 13 | Get Operating System Version Information |
| 123 | 14 | Get Active Connection List by Type |
| 123 | 15 | Get NLM Resource Tag List |
| 123 | 20 | Active LAN Board List |
| 123 | 21 | LAN Configuration Information |
| 123 | 22 | LAN Common Counters Information |
| 123 | 23 | LAN Custom Counters Information |
| 123 | 25 | LSL Information |
| 123 | 26 | LSL Logical Board Information |
| 123 | 30 | Get Media Manager Object Information |
| 123 | 31 | Get Media Manager Objects List |
| 123 | 32 | Get Media Manager Children’s List |
| 123 | 33 | Get Volume Segment List |
| 123 | 40 | Active Protocol Stacks |
| 123 | 41 | Get Protocol Stack Configuration Information |
| 123 | 42 | Get Protocol Stack Statistics Information |
| 123 | 43 | Get Protocol Stack Custom Information |
| 123 | 44 | Get Protocol Stack Numbers by Media Number |
| 123 | 45 | Get Protocol Stack Numbers by LAN Board Number |
| 123 | 46 | Get Media Name by Media Number |
| 123 | 47 | Get Loaded Media Number List |
| 123 | 50 | Get General Router and SAP Information |
| 123 | 51 | Get Network Router Information |
| 123 | 52 | Get Network Routers Information |
| 123 | 53 | Get Known Networks Information |
| 123 | 54 | Get Server Information |
| 123 | 55 | Get Server Sources Information |
| 123 | 56 | Get Known Servers Information |
| 123 | 60 | Get Server Set Commands Information |
| 123 | 61 | Get Server Set Categories |
операций службы каталогов Netware
10.5 Таблица операций службы каталогов Netware
| Код операции | Описание |
| 0x01 | Resolve Name |
| 0x02 | Read Entry Information |
| 0x03 | Read |
| 0x04 | Compare |
| 0x05 | List |
| 0x06 | Search Entries |
| 0x07 | Add Entry |
| 0x08 | Remove Entry |
| 0x09 | Modify Entry |
| 0x0A | Modify Relative Distinguished Name |
| 0x0B | Define Attribute |
| 0x0C | Read Attribute Definition |
| 0x0D | Remove Attribute Definition |
| 0x0E | Define Class |
| 0x0F | Read Class Definition |
| 0x10 | Modify Class Definition |
| 0x11 | Remove Class Definition |
| 0x12 | List Containable Classes |
| 0x13 | Get Effective Rights |
| 0x14 | Add Partition |
| 0x15 | Remove Partition |
| 0x16 | List Partitions |
| 0x17 | Split Partition |
| 0x18 | Join Partition |
| 0x19 | Add Replica (копия секции каталога) |
| 0x1A | Remove Replica |
| 0x1B | Open Stream |
| 0x1D | Create Subordinate Reference |
| 0x1E | Link Replica |
| 0x1F | Change Replica Type |
| 0x20 | Start Update Schema |
| 0x21 | End Update Schema |
| 0x22 | Update Schema |
| 0x23 | Start Update Replica |
| 0x24 | End Update Replica |
| 0x25 | Update Replica |
| 0x26 | Synchronize Partition |
| 0x27 | Synchronize Schema |
| 0x29 | Get Replica Root ID |
| 0x2A | Begin Move Entry |
| 0x2B | Finish Move Entry |
| 0x2C | Release Move Entry |
| 0x2D | Backup Entry |
| 0x2E | Restore Entry |
| 0x32 | Close Iteration |
| 0x35 | Get Server Address |
| 0x36 | Set Keys |
| 0x3B | Begin Authentication |
| 0x3C | Finish Authentication |
| 0x3F | Repair Timestamps |
| 0x40 | Create Back Link |
| 0x41 | Delete External Reference |
| 0x42 | Rename External Reference |
| 0x43 | Create Entry Directory |
| 0x44 | Remove Entry Directory |
| 0x45 | Designate New Master |
| 0x46 | Change Tree Name |
| 0x47 | Partition Entry Count |
| 0x48 | Check Login Restrictions |
| 0x49 | Start Join |
| 0x4A | Low Level Split |
| 0x4B | Low Level Join |
| 0x4C | Abort Low Level Join |
| 0x4D | Get All Servers |
Основные NCP-функции
Таблица 4.2.1.5.1 Основные NCP-функции
|
Вид сервиса |
Тип запроса |
Код операции |
Код субфункции |
|
ping для nds ncp (запрос о NDS) |
2222 |
104 |
01 |
|
Посылка фрагментированного NDS запроса/отклика |
2222 |
104 |
02 |
|
Закрытие NDS-фрагмента |
2222 |
104 |
03 |
|
Возврат контекста bindary |
2222 |
104 |
04 |
|
Мониторирование NDS-связи |
2222 |
104 |
05 |
Запрос nds в режиме ping позволяет запросить сервер о поддержке им операции с кодом 104. Если сервер может выполнить эту операцию, он посылает позитивный отклик, который содержит имя дерева каталога и его глубину. При посылке фрагментированного nds запроса присылается фрагментированный отклик. При обновлении секции каталога netware передает последовательность nds-фрагментов, содержащих изменения данной секции. Формат таких пакетов показан на Рисунок 4.2.1.5.1. В скобках указаны размеры полей в байтах. Поле максимальный размер фрагмента несет в себе максимальное число байт, которое может быть послано в качестве отклика. Код в этом поле соответствует максимуму, поддерживаемому сетевой средой минус 8 (сумма длин поля длины отклика и поля дескриптора фрагмента). Поле флага фрагмента всегда содержит нуль. Поле внутренняя функция хранит в себе код операции для службы каталогов netware.
Параметры различных локальных сетей
Таблица 4.1. Параметры различных локальных сетей
|
Название сети |
Топология |
Быстродействие Мбит/с |
Доступ |
Тип кабеля |
NEXT при макс. частоте [дб] |
Размер сети (сегмента) |
Макс. число узлов |
| 10base5 | шина | 10 | CSMA/CD | RG-58 (50 Ом) | 500м | 1024 | |
| 10base2 | шина | 10 | CSMA/CD | RG-58 (50 Ом) | 185 м | 90 | |
| 10base-t | шина | 10 | CSMA/CD | UTP (III; 100 Ом) | 26 | 100 м | - |
| 10broad36 | шина | 10 | CSMA/CD | RG-59 (75 Ом) | 3600 м | 1024 | |
| 100base-tx | звезда | 100 | CSMA/CD | UTP (v; 100 Ом) | 29 | 200 м | - |
| 100base-fx | звезда | 100 | CSMA/CD | оптоволокно | 300 м | - | |
| 100base-t4 | звезда | 100 | CSMA/CD | UTP (III; 100 Ом) | 21 | 200 м | - |
| 1base5 (starlan) | шина/ звезда | 1 | CSMA/CD | UTP (II) | 22 | 400 м | 1210 |
| IEEE 802.4 | шина | 1/5/10/20 | маркер | RG-59 (75 Ом) | |||
| Arcnet | звезда | 2,5/20 | маркер | RG-62/utp (93 Ом) | 600/125м | 255 | |
| IEEE 802.5 | звезда | 4/16 | маркер | STP/UTP (150/120 Ом) | 22/32 | 366 м | 260 |
| Appletalk | шина/ звезда |
0,23 | CSMA/CD | STP/UTP (100 Ом) | 22/32 | 300/3000 м | 32 на сегмент |
| Ethertalk | шина/
звезда |
10 | CSMA/CD | STP/UTP, коаксиальный кабель | 500/3000 м | 254/1023 | |
| ISN | звезда | 8,64 | Шина доступа | stp, оптоволокно | Не ограничено | 336/1920 | |
| pc lan | дерево, звезда | 2 | CSMA/CD | RG-59 (75 Ом), UTP/STP |
32/22 |
2000 | 72 |
| Hyperchannel | шина | 50 | CSMA/CD | RG-59, оптоволокно | 3500 м | 256 | |
| e-net | шина | 10 | CSMA/CD | RG-58 (50 Ом) | 700 м | 100 | |
| G-net | шина | 1 | CSMA/CD | RG-58, RG-59 | 2000 м | 100 | |
| FDDI | Двойное кольцо | 100 | маркер | оптоволокно | 100км | 1000 | |
| PX-net | шина/ звезда | 1 | маркер | RG-62 (93 Ом) | 7000 м | 100 | |
| S-net | шина/ звезда | 1 | Индивидуальный | STP (100 Ом) | 21 | 700 м | 24 |
| wangnet | двойное дерево | 10 | CSMA/CD | RG-59 (75 Ом) | 2800 м | 65000 |
Приведенная таблица не может претендовать на полноту. Так сюда не вошла сеть IBM DSDB, разработанная в начале 80-х годов. Полоса пропускания сети составляет 64 Мбит/с. Эта сеть рассчитана на обслуживания процессов реального времени. Сеть имеет топологию шины с приоритетным доступом (длина шины до 500м).
Для каждого канала выделяется полоса 5 Мбит/с (полоса пропускания 6МГц соответствует телевизионному стандарту). Предусматривается 5 передающих (59,75-89,75 МГц) и 5 принимающих (252-282 МГц) каналов для каждого из сетевых сегментов. Частота ошибок (BER) для сети данного типа меньше 10-8.
Другой Ethernet-совместимой сетью является Fibercom Whispernet. Сеть имеет кольцевую структуру (до 8км), полосу пропускания 10Мбит/c, число узлов до 100 на сегменте при полном числе узлов в сети – 1024. Число кольцевых сегментов может достигать 101. Максимальное межузловое расстояние – 2км.
Примером нетрадиционного типа сети может служить Localnet 20 (Sytek). Сеть базируется на одном коаксиальном кабеле и имеет полную полосу пропускания 400 МГц. Сеть делится на 120 каналов, каждый из которых работает со скоростью 128 Кбит/с. Каналы используют две 36МГц-полосы, одна для передачи, другая для приема. Каждый из коммуникационных каналов занимает 300КГц из 36МГц. Сеть использует алгоритм доступа CSMA/CD, что позволяет подключать к одному каналу большое число сетевых устройств. Предусматривается совместимость с интерфейсом RS-232. Частота ошибок в сети не более 10-8.
Фирма Дженерал Электрик разработала сеть gm (map-шина), совместимую со стандартом IEEE 802.4. Целью разработки было обеспечение совместимости с производственным оборудованием различных компаний. Сеть рассчитана на работу со скоростями 1, 5 и 50 Мбит/с.
Традиционные сети и телекоммуникационные каналы образуют основу сети – ее физический уровень. Реальная топология сети может динамически изменяться, хотя это и происходит обычно незаметно для участников. При реализации сети используются десятки протоколов. В любых коммуникационных протоколах важное значение имеют операции, ориентированные на установление связи (connection-oriented) и операции, не требующие связи (connectionless - "бессвязные", ISO 8473). Интернет использует оба типа операций. При первом типе пользователь и сеть сначала устанавливают логическую связь и только затем начинают обмен данными.
Причем между отдельными пересылаемыми блоками данных (пакетами) поддерживается некоторое взаимодействие. "Бессвязные" операции не предполагают установления какой-либо связи между пользователем и сетью (например, протокол UDP) до начала обмена. Отдельные блоки передаваемых данных в этом случае абсолютно независимы и не требуют подтверждения получения. Пакеты могут быть потеряны, задублированы или доставлены не в порядке их отправки, причем ни отправитель, ни получатель не будут об этом оповещены. Именно к этому типу относится базовый протокол Интернет - IP.
Для каждой сети характерен свой интервал размеров пакетов. Среди факторов, влияющих на выбор размеров можно выделить
Аппаратные ограничения, например размер домена при мультиплексировании по времени.
Операционная система, например размер буфера 512 байт.
Протокол (например, число бит в поле длины пакета).
Обеспечение совместимости с определенными стандартами.
Желание уменьшить число ошибок при передаче ниже заданного уровня.
Стремление уменьшить время занятости канала при передаче пакета.
Ниже приведены максимальные размеры пакетов (mtu) для ряда сетей
| Сеть | MTU Байт |
Быстродействие Мбит/с |
| IEEE 802.3 | 1500 | 10 |
| IEEE 802.4 | 8191 | 10 |
| IEEE 802.5 | 5000 | 4 |
Операции, ориентированные на установление связи (например, протокол TCP), предполагают трехстороннее соглашение между двумя пользователями и провайдером услуг. В процессе обмена они хранят необходимую информацию друг о друге, с тем, чтобы не перегружать вспомогательными данными пересылаемые пакеты. В этом режиме обмена обычно требуется подтверждение получения пакета, а при обнаружении сбоя предусматривается механизм повторной передачи поврежденного пакета. "Бессвязная" сеть более надежна, так как она может отправлять отдельные пакеты по разным маршрутам, обходя поврежденные участки. Такая сеть не зависит от протоколов, используемых в субсетях. Большинство протоколов Интернет используют именно эту схему обмена. Концептуально TCP/IP-сети предлагают три типа сервиса в порядке нарастания уровня иерархии:
"бессвязная" доставка пакетов;
надежная транспортировка информации;
реализация прикладных задач.
Немногие из читателей участвуют в создании региональных и тем более глобальных сетей, за то структура и принципы построения локальных сетей им, безусловно, близки. На Рисунок 4.4 и 4.5 приведены два варианта “ресурсных” локальных сетей (сети для коллективного использования ресурсов – памяти, процессоров, принтеров, магнитофонов и т.д.). Такие сети строятся так, чтобы пропускная способность участков, где информационные потоки суммируются, имели адекватную полосу пропускания. Эффективность сети на Рисунок 4.4 сильно зависит от структуры и возможностей контроллеров внешних устройств, от объема их буферной памяти.
Точность и стабильность часов для различных слоев
Таблица 4.4.15.12. Точность и стабильность часов для различных слоев
Слой |
Минимальная точность (за день) |
Минимальная стабильность (за день) |
1 |
1 x 10-11 |
Не специфицировано |
2 |
1.6 x 10-8 |
1 x 10-10 |
3 |
4.6 x 10-6 |
3.7 x 10-7 |
4 |
3.2 x 10-5 |
Не специфицировано |
Конструкция, работа и характеристики осциллятора слоя 1 предполагаются сопоставимыми с национальными стандартами времени и часто базируются на цезиевом стандарте. Часы слоя 4 соответствуют требованиям обычных цифровых каналов и систем PBX. Слои 2-3 могут использоваться для работы с мощными синхронными каналами связи.
Раздача времени и частоты
Для того чтобы атомное и обычное время могли быть взаимосвязаны, национальные администрации обеспечивают работу первичных стандартов времени и частоты и совместно координируют их функционирование. Большинство морских держав поддерживают широковещательные радиослужбы времени.
Американский Национальный Институт Стандартов и Технологии (NIST – National Institute of Standards and Technology) поддерживает три радиослужбы для рассылки временной информации. Одна из них использует передачу (ВЧ или CCIR диапазон 7) на частотах 2.5, 5, 10, 15 и 20 Мгц. Сигнал распространяется, отражаясь от верхних слоев атмосферы, что неизбежно приводит к непредсказуемым вариациям задержки на принимающей стороне. С 60-секундным интервалом передается временной код, который транслируется на 100 килогерцной субнесущей со скоростью передачи 1 бит/с. Этот код содержит информацию об UTC времени и дате, но не включает в себя данных о текущем годе и оповещения о добавлении/вычитании секунды для последней минуты данного дня. Существуют и другие сходные службы времени (например, в Оттаве), гарантирующие точность на уровне 1-10 мсек.
Вторая служба времени NIST использует передачу (НЧ или CCIR диапазон 5) на частоте 60 КГц, она доступна на континентальной части США и вблизи берегов. Сигнал распространяется в нижней части атмосферы и по этой причине слабо подвержен вариациям времени распространения.
Временной код передается с периодом в 60 секунд со скоростью 1 бит/с. Достижимая точность составляет 50 миллисекунд [BLA74]. Ряд европейских стран предлагают аналогичные службы времени (Великобритания - MSF; Германия - DCF77). Коды времени здесь включают информацию о текущем годе и предупреждение о добавляемой/вычитаемой секунде. Третья служба NIST использует передачу на частоте 468 МГц (УВЧ или CCIR диапазон 9) с геостационарных спутников GOES, три из которых перекрывают западное полушарие. Временной код перемежается с сообщениями, адресованными удаленным датчикам и состоит из 600 4-битовых слов, передаваемых с периодом в 30 секунд. Временной код содержит информацию об UTC времени-дне-годе, а также предупреждение о добавлении/вычитании секунды в конце дня. Точность этой службы составляет 0,5 мсек.
Министерство обороны США разработало глобальную систему определения координат GPS (Global Positioning System). Эта система базируется на 24 спутниках, движущихся по орбитам с периодом 12 часов. Система GPS может обеспечить точность определения времени на уровне нескольких наносекунд [VAN84].
Американская береговая охрана в течение многих лет использует службу радионавигации LORAN-C [FRA82]. Эта служба обеспечивает временную точность менее 1 мксек.
Система радионавигации военно-морского флота США и других стран OMEGA [VAS78] состоит из 8 передатчиков, работающих на частотах от 10.2 до 13.1 КГц (УНЧ или CIR диапазон 4) и перекрывающих весь земной шар 24 часа в сутки. Точность этой системы составляет около 1 мсек. Система OMEGA обеспечивает высокую точность для частоты, но не передает временного кода. По этой причине приемник должен предварительно получить географические координаты с точностью до градуса и время UTC с точностью 5 секунд от независимых источников.
Заметим, что не все службы времени передают информацию о текущем годе и предупреждения о добавлении/вычитании секунды. Протокол NTP позволяет решить эту проблему.
Определение частоты
В течение многих лет наиболее важным использованием времени и частоты были всемирная навигация и космическая наука, которые зависят от наблюдений солнца, луны и звезд.
За стандартную секунду (в 1957 году) принята 1/31,556,925. 9747 периода вращения Земли вокруг Солнца (тропический год). Согласно этой шкалы тропический год длится 365.2421987 дней, а лунный месяц 29.53059 дней. Однако тропический год может быть определен лишь с точностью около 50 мсек.
С древнейших времен человечеству были известны три осциллятора (процесса задающих временную шкалу) - вращение земли вокруг своей оси, вращение Луны вокруг Земли и вращение Земли вокруг Солнца. К сожалению, с точки требований современных технологий все эти три осциллятора не обладают достаточной стабильностью. В 1967 стандартная секунда была переопределена и теперь равняется 9,192,631,770 периодов перехода в атоме цезия-133. С 1972 стандарты времени и частоты базируются на международном атомном времени TAI (International Atomic Time). Точность таких часов составляет около микросекунды в сутки. Важно то, что новая шкала абсолютно однородна и не подвержена дрейфам.
Определение времени и необходимости добавления/вычитания секунды
Международное бюро мер и стандартов IBWM (International Bureau of Weights and Measures) использует астрономические наблюдения, выполненные морской обсерваторией США и другими обсерваториями для определения UTC.
Для более точной временной привязки событий после 1972 года необходимо знать, когда вставлялись или удалялись секунды коррекции (удаление пока никогда не производилось). Как определено в докладе 517 CCIR, который воспроизведен в [BLA74], дополнительные секунды вставляются после 23:59:59 в последний день июня или декабря. Неоднородность во временную шкалу (TAI) помимо добавляемых секунд вносят также 100 миллисекундные коррекции UT1, называемые DUT1, которые служат для повышения точности при навигации. Следует признать, что момент добавления секунды является началом новой (однородной) временной шкалы.
Временная шкала NTP базируется на шкале UTC, но необязательно всегда совпадает с ней. В 0 часов 1 января 1972 начинается эра UTC, часы NTP были установлены на 2,272,060,800 стандартных секунд после 0 часов 1 января 1900.
возможных значений поля
Таблица возможных значений поля класс партнера приведена ниже. Поле имя партнера может иметь до 32 октетов.
Значения кодов индикатора LI
Таблица 4.4.15.1 Значения кодов индикатора LI
|
LI |
Величина |
Значение |
00 |
0 |
предупреждения нет |
01 |
1 |
последняя минута содержит 61 секунду |
10 |
2 |
последняя минута содержит 59 секунд |
11 |
3 |
аварийный сигнал (часы не синхронизованы) |
Во всех случаях за исключением аварийного сигнала (alarm = 112), протокол NTP никак не изменяет эти биты, а только передает их программам преобразования времени, которые не являются частью протокола. Аварийная ситуация возникает, когда по какой-либо причине локальные часы оказываются не синхронизованными. Это может случиться в ходе инициализации системы или в случае, когда первичные часы оказываются недоступны в течение длительного времени.
Режим (peer.mode, pkt.mode) - это целое 3-битовое число, обозначающее код режима ассоциации, который может принимать значения, приведенные в таблице 4.4.15.2:
Значения кодов поля тип запроса
Таблица 4.2.1.3.1 Значения кодов поля тип запроса
|
Код |
Описание запроса |
1111 |
Создание канала обслуживания |
2222 |
Запрос сервиса |
5555 |
Ликвидация канала обслуживания |
7777 |
Пересылка в пакетном режиме |
Поле номер по порядку используется для отслеживания последовательности связи между клиентом и сервером. Клиент записывает в это поле код, равный номеру по порядку плюс единица. В полях номера канала записан номер, присвоенный клиенту при его регистрации сервером. Поле номер задачи идентифицирует каждую из задач, сделавших запрос. Сервер следит за выполнением задачи и освобождает ресурсы при завершении выполнения. Номер задачи равный нулю говорит серверу, что все задания окончены. Старшая часть номера канала используется лишь при наличии более чем 1000 пользователей, в остальных вариантах это субполе содержит нуль. Сервер в своем отклике сообщает клиенту результаты выполнения его запроса. Отклик, также как и запрос, вкладывается в IPX/SPX-пакет. Формат пакета-отклика показан на Рисунок 4.2.1.3.2.
Значения кодов Режим
Таблица 4.4.15.2. Значения кодов Режим
|
Режим |
Значение |
0 |
зарезервировано |
1 |
симметричный активный |
2 |
симметричный пассивный |
3 |
клиент |
4 |
сервер |
5 |
широковещательный |
6 |
для управляющих сообщений NTP |
7 |
зарезервировано для частного использования |
Слой (sys.stratum, peer.stratum, pkt.stratum) - это целое число, указывающее код слоя локальных часов, который может принимать значения приведенные в таблице 4.4.15.3.
Значения кодов слой
Таблица 4.4.15.3. Значения кодов слой
|
Слой |
Значение |
0 |
Не специфицирован или недоступен |
1 |
Первичный эталон (например, радио часы) |
2-15 |
Вторичный эталон (через NTP или sntp) |
16-255 |
Зарезервировано на будущее |
Для целей сравнения значение нуль для кода слоя считается выше, чем любая другая величина. Заметим, что максимальное значение целого, закодированное как пакетная переменная, ограничено параметром ntp.maxstratum.
Период обмена (sys.poll, peer.hostpoll, peer.peerpoll, pkt.poll). Это целая переменная со знаком, указывающая минимальный интервал между передаваемыми сообщениями, измеренный в секундах и представленный как степень 2. Например, значение 6 указывает на минимальный интервал в 64 секунды.
Точность (sys.precision, peer.precision, pkt.precision). Это целая переменная со знаком, обозначающая точность часов в секундах и выраженная как ближайшая степень числа 2. Значение должно быть округлено в большую сторону до ближайшего значения степени 2, например, сетевой частоте 50-Гц (20 мс) или 60-Гц (16.67 мс) будет поставлено в соответствие величина -5 (31.25 мс), в то время как кварцевой частоте 1000-Гц (1 мс) будет поставлено в соответствие значение -9 (1.95 мс).
Базовая задержка (sys.rootdelay, peer.rootdelay, pkt.rootdelay). Это число с фиксированной запятой со знаком, указывающее на величину полной циклической задержки (RTT) до первичного эталона частоты, выраженной в секундах.
Базовая дисперсия (sys.rootdispersion, peer.rootdispersion, pkt.rootdispersion). Это число с фиксированной запятой больше нуля, указывающее на максимальное значение временной ошибки по отношению к первичному эталону в секундах.
Идентификатор эталонных часов (sys.refid, peer.refid, pkt.refid). Это 32-битовый код, идентифицирующий конкретные эталонные часы. В случае слоя 0 (не специфицирован) или слоя 1 (первичный эталонный источник), 4-октетная ASCII-строка, выровненная по левому краю и дополненная при необходимости нулями, например:
Вариант схемы ресурсной локальной сети
Рисунок 4.4. Вариант схемы ресурсной локальной сети
Сеть, показанная на Рисунок 4.5, несравненно более эффективна (практически исключены столкновения и легче гарантировать определенное время доступа к ресурсу). Здесь также немало зависит от свойств контроллеров внешних ресурсов (помечены красным цветом). Но такие сети обычно более дорого реализовать.
Влияние шумов и помех
2.1.1 Влияние шумов и помех
Шумы определяют емкость канала и задают частоту ошибок при передаче цифровых данных. Шум по своей природе нестабилен и можно говорить лишь о том, что его величина с некоторой вероятностью лежит в определенном интервале значений. Плотность вероятности p(x) определяет вероятность того, что случайный сигнал X имеет значение амплитуды в интервале между x и x+Dx. При этом вероятность того, что значение х лежит в интервале между x1 и x2 определяется равенством:
P(x) – вероятность, а p(x) – плотность вероятности. Вероятность того, что x меньше некоторой величины y равна
Так называемый белый шум подчиняется непрерывному нормальному (Гауссову) распределению
В этом случае, если мы хотим знать вероятность того, что амплитуда шумового сигнала лежит в пределах ±
v, то можно воспользоваться выражением
Для вычисления P{x1<x<-x1} обычно используются равенства
Распределение P(x) обычно называется функцией ошибок (erf(x) = -erf(-x)). Полезной с практической точки зрения является вероятность
P{-kss}=Pk(k s) =
Из числа дискретных распределений наиболее часто используемым является распределение Пуассона.
Среднее значение x
Как уже говорилось, во многих случаях шум имеет гауссово распределение с нулевым средним значением амплитуды. В этих случаях среднее значение мощности шумового сигнала равно вариации функции плотности вероятности. В этом случае отношение сигнал-шум будет равно
Шум определяет вероятность ошибки при передаче сообщения по каналу связи и, в конечном итоге, пропускную способность канала (см. теорему Шеннона; раздел 2.1 Передача сигналов по линиям связи ).
Выбор маршрута нового виртуального канала при наличии перегрузки
Рисунок 4.7. Выбор маршрута нового виртуального канала при наличии перегрузки
На Рисунок 4.7 (верх) показан пример сети с двумя узлами, характеризующимися перегрузкой (помечены красным цветом). Предположим, что необходимо проложить виртуальный канал из узла А в узел Б. Из графа маршрутов удаляются перегруженные узлы, после чего осуществляется прокладка пути. В нижней части рисунка синим цветом показан новый виртуальный канал.
Еще более универсальным решение, пригодным для работы с установлением соединения и без, является посылка пакетов блокировки (choke packets). Маршрутизатор обычно контролирует загруженность всех своих внешних каналов l, которая может принимать значения от 0 до 1. Когда l достигает некоторого порогового значения, отправителю посылается пакет блокировки. При вычислении l следует использовать какую-либо методику усреднения, чтобы избежать слишком частых блокировок.
Когда отправитель получает пакет блокировки, он должен уменьшить трафик, посылаемый получателю на заданное число процентов. Так как на пути к месту назначения может быть много пакетов, это вызовет серию пакетов блокировки. Отправитель должен игнорировать пакеты блокировки в течение некоторого времени после получения первого такого пакета. По истечении этого периода отправитель прослушивает канал на протяжении аналогичного времени, ожидая получения новых пакетов блокировки. Если такой пакет приходит, канал все еще перегружен и отправитель снова должен понизить темп посылки пакетов. Если на протяжение периода прослушивания не приходит новых пакетов блокировки, отправитель может увеличить поток снова.
ЭВМ может понижать трафик, корректируя свои параметры, например, ширину окна или темп передачи на выходе устройства типа "дырявое ведро". Обычно первый блокирующий пакет уменьшает поток вдвое, следующий на 0,25 от первичного и т.д. Увеличение потока также производится аналогичными шагами. Существует большое число вариантов алгоритма управления потоком с использованием пакетов блокировки.
Параметром, который контролируется и определяет условие отправки пакета блокировки, может служить длина очереди или заполненность буфера.
Ситуация перегрузки не всегда управляется однозначно. Например, при поступлении на вход пакетов от трех источников возможна ситуация, когда приемник посылает блокирующие пакеты всем отправителям, а откликнется сокращением потока только один. В результате этот узел, который "играет по правилам" (как это часто бывает и в жизни) оказывается в проигрыше. В 1987 году Нагле был предложен алгоритм fair queueing (честная очередь). В этом алгоритме маршрутизатор организует независимые очереди для пакетов, поступающих от разных источников. Когда выходной канал маршрутизатора оказывается свободным, он просматривает очереди циклически и отравляет очередной пакет. В результате при n очередях по завершении такого цикла просмотров-посылок оказываются посланы по одному пакету из каждой очереди. Такой алгоритм используется в некоторых ATM-переключателях. Следует заметить, что этот алгоритм дает некоторые преимущества тем узлам, которые посылают более длинные пакеты. Демерс (Demers) и др. в 1990 году предложил некоторое усовершенствоввание алгоритма. В данном варианте организуется циклический просмотр очередей не по-пакетно, а по-байтно. Система последовательно сканирует очереди и определяет положение концов пакетов. Первыми отправляются более короткие пакеты. Для иллюстрации предлагается рассмотреть Рисунок 4.8. (см. также [39])
