Интегрированные сети ISDN

         

Формат диагностического запроса



Рисунок 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).

Пакет NETBIOS (см. также

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, содержит:



AS:
(A, B, IA1) (1)
Здесь предполагается, что сообщение послано открытым текстом, но в принципе оно может быть и зашифровано с использованием ключа KA.



AS:
(A, B, IA1)KA (1.1)
Получив это сообщение AS , извлекает из базы данных секретные ключи KA и KB, а также вычисляет новый ключ CK (ключ сессии), который будет использован для осуществления процедуры аутентификации. Этот новый ключ должен быть непредсказуемым, он используется только для одной операции аутентификации.

Далее AS посылает субъекту А следующее сообщение:

AS®

A:
(IA1, B, CK, {CK, A}KB)KA (1.2)
Верхний индекс в данном выражении означает, что содержимое в скобках зашифровано с использованием ключа-индекса. КА и КВ – секретные ключи субъектов А и В, соответственно.

Так как выражение (IA1, B, CK, {CK, A}KB) зашифровано ключом КА, то только субъект А может его дешифровать и прочесть. Субъект А проверяет наличие идентификатора IA1 (это подтверждает то, что данное сообщение является откликом на сообщение А), и имени субъекта, с которым А намерен обмениваться данными (В). В результате дешифровки сообщения от AS А получает во владение рабочий ключ СК. Наличие В в сообщение является обязательным. В противном случае злоумышленник может заменить В на, например, Х в сообщении (1), и в дальнейшем А будет взаимодействовать с Х а не с В, сам того не подозревая.


Заметим, что часть текста {CK, A}KB субъект А прочесть не может.

Если все прошло нормально, субъект А посылает В следующее сообщение:



B:
{CK, A}KB (1.3)
Нетрудно видеть, что содержимое {CK, A}KB является частью сообщения, полученного от AS. Дешифровать это послание может только субъект В, так как оно зашифровано его секретным ключом. После дешифровки В также становится владельцем ключа сессии CK. Наличие А в сообщении подтверждает факт, что код получен именно от данного субъекта. Все обмены между А и В далее будут выполняться с использованием ключа шифрования СK. Чтобы сделать схему симметричной и уменьшить вероятность атаки воспроизведения, В следует послать А свой идентификатор:



A:
{IB}CK (1.4)
зашифрованный ключом СК. При этом ожидается отклик:



B:
{IB-1}CK (1.5)
Таким образом, в данной версии протокола используется 5 сообщений. Злоумышленник не может имитировать такой обмен, так как не владеет ключом CK. Это число для регулярно взаимодействующих партнеров можно сократить до трех, убрав обмен сообщениями 1.1 и 1.2. При этом ключ СК будет использоваться многократно. Здесь желательно заменить обмены 1.3 и 1.4 на:



B:
{CK, A}KB, {IA2}CK (1.3a)


A:
{IA2 –1, IB}CK (1.4a)
Теперь рассмотрим вариант протокола для случая асимметричного шифрования (двух ключевая схема).

Предполагается, что субъекты А и В вычислили пары ключей (PKA-SKA) и (PKB-SKB), соответственно. Имена ключей, начинающиеся с буквы P, относятся к общедоступным ключам (public), а имена, начинающиеся с буквы S, - к секретным. Инициатором, как и в предыдущем случае, будем считать субъект А. Обмен начинается с посылки AS запроса открытого ключа В (PKB).



AS:
(A, B) (2.1)
AS откликнется сообщением:

AS®

A:
(PKB, B)SKAS (2.2)
Сообщение зашифровано секретным ключом AS (SKAS). Открытый ключ AS (PKAS) предполагается А известным, что позволяет А успешно дешифровать данное сообщение. Здесь предполагается, что подмена ключей (SKAS-PKAS) злоумышленником-посредником невозможна.



Шифрование данных с использованием ключа SKAS не гарантирует конфиденциальности, но исключает модификацию сообщения по дороге (ведь никто посторонний не знает ключ SKAS). Важно, чтобы субъект А был уверен, что он получил именно PKB, а не что-то иное. Следующим шагом будет посылка сообщения от А к В:



B:
{IA, A}PKB (2.3)
Это сообщение может быть дешифровано только субъектом В. Смысл его заключается в том, что А уведомляет В о намерении установить с ним связь, и передает ему свой одноразовый идентификатор IA. Далее В запрашивает у AS открытый ключ А:



AS:
B, A (2.4)
AS®

B:
{PKA, A}SKAS (2.5)
После этого производится взаимная аутентификация субъектов, завершающая сессию, для чего посылаются сообщения:



A:
{IA, IB}PKA (2.6)


B:
{ IB }PKB (2.7)
Таким образом, в этом варианте аутентификация потребовала семи шагов, но 4 из них (2.1, 2.2, 2.4 и 2.5) могут быть устранены, если партнеры помнят общедоступные ключи друг друга. В этом случае схема становится эквивалентной приведенной выше версии с симметричным шифрованием.

Так как открытые ключи общедоступны, во многих случая для обеспечения большей достоверности следует использовать шифрование типа:

{{сообщение}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)
IA1 передается для того, чтобы сохранить состояние ASA между сообщениями 1.11 и 1.12.



При работе с открытыми ключами возможно непосредственное обращение А к ASB, если субъект А владеет общедоступным ключом PKASB. По минимуму аутентификация при асимметричной схеме шифрования требует пересылки трех сообщений.

Протокол Нидхэма-Шрёдера пригоден и для работы с электронными подписями. Электронная подпись, как обычно, формируется на основе дайджеста D (например, MD5) пересылаемого документа. Сначала рассмотрим вариант с традиционной схемой шифрования. Субъект А начинает передачу с посылки AS сообщения:



AS:
(A, {D}KA) (3.1)
AS откликается, послав:

AS®

A:
{A, D}KAS (3.2)
Сообщение 3.2 зашифровано ключом AS и, следовательно, не может дешифровано А. Субъект А шлет документ субъекту В с блоком подписи, следующим за текстом. При получении В сначала дешифрует текст и вычисляет дайджест документа CD, затем посылает блок подписи в AS для дешифровки.



AS:
B, {A, D}KAS (3.3)
Сервер дешифрует блок подписи и возвращает результат В:

AS®

B:
{A, D}KB 3.4)
Если возвращенный дайджест D соответствует CD, тогда субъект, упомянутый в 3.4, является отправителем подписанного текста. Если соответствия нет, это означает, что на этапах 3.1 –3.4 произошло искажение блока подписи или самого текста.

В случае варианта шифрования с общедоступными ключами схема электронной подписи упрощается. В этом варианте можно даже не формировать дайджест можно послать текст, зашифрованный сначала секретным ключом А, а затем с привлечением общедоступного ключа В.



B:
{ (текст)SKA }PKB  
Субъект-получатель В дешифрует полученный текст сначала с помощью своего секретного ключа (SKB), а затем с привлечением общедоступного ключа А (PKA). При такой схеме А не сможет отказаться от того, что именно он послал текст, так как только он владеет секретным ключом SKA. Прочесть же текст может только субъект В, так как только он владеет секретным ключом SKB.

В настоящее время разработан улучшенный протокол Нидхэма-Шрёдера (см.

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 далее следует список групп новостей
Команда NEWGROUPS date time [GMT] [<distributions>]

Список групп новостей создан с <date и time> будет представлен в том же формате, что и в случае команды LIST.

Дата посылается в виде 6 цифр в формате ГГММДД, где ГГ последние две цифры года, MM – номер месяца (с нулем в начале, если требуется) и ДД номер дня в месяце. Дополнение для года берется из предположения о ближайшем тысячелетии, так 86 предполагает 1986, 30 - 2030, 99 - 1999, а 00 – 2000 годы.

Время должно характеризоваться также 6 цифрами в формате ЧЧMMСС, где ЧЧ – часы с начала суток в 24-часовом исчислении, MM минуты 00-59, а СС секунды 00-59.


Временная зона определяется сервером, в противном случае появляется символьная комбинация "GMT", в этом случае и время и дата привязаны к нулевому меридиану.

Опционный параметр "distributions" представляет собой список групп рассылки, заключенный в угловые скобки. Если параметр задан, рассылаемая часть новых групп новостей будет сравниваться с данным списком, и только при совпадении включается в список. Если необходимо использовать более одного такого фильтра, то они разделяются друг от друга запятыми в пределах угловых скобок.

Отклик: 231 далее следует список новых групп
Команда NEWNEWS newsgroups date time [GMT] [<distribution>]



Команда формирует список идентификаторов статей для заданной группы новостей, с датой после указанной. Для каждого идентификатора сообщения в списке выделяется одна строка. Список завершается строкой с одиночным символом точки, за которым следует CR-LF. Дата и время задаются в том же формате, что и для команды NEWGROUPS.

Для расширения зоны поиска в имени группы новостей можно использовать символ "*". Программа может подставить вместо звездочки любую комбинацию символов. Если вместо имени группы подставлен символ звездочка, поиск будет проведен по всем группам новостей.

Если звездочка в имени группы отсутствует, новые статьи будут искаться только в группе, имя которой приведено в качестве параметра запроса. Имя группы должно быть взято из списка доступных групп. Допускается спецификация нескольких групп (имена разделяются запятыми). После последнего имени группы не должно быть запятой.

Для отрицания соответствия может использоваться восклицательный знак. Это можно использовать для селективного исключения определенных групп новостей с целью сокращения размера списка. Например, спецификация групп "net.*,mod.*,!mod.map.*" определяет, что следует просмотреть все статьи в группах net.<что-то> и mod.<что-то> за исключением mod.map.<что-то>. Восклицательный знак должен использоваться непосредственно перед первым символом выбранного имени группы новостей.



Опционный параметр "distributions" представляет собой список групп рассылки, заключенный в треугольные скобки. Если этот параметр задан, производится отбор статей, соответствующих категориям, приведенным в списке distribution.

Заметьте, что пустой список является вполне допустимым откликом и означает отсутствие новых статей.

Отклик: 230 далее следует список идентификаторов новых статей
Команда NEXT

Команда перемещает указатель текущей статьи на следующую запись в текущей группе новостей. Если в группе нет больше статей, посылается сообщение об ошибке, а указатель текущей статьи остается не измененным.

В качестве отклика на команду возвращается номер текущей статьи и идентификатор сообщения. Никаких текстовых сообщений не посылается.

Отклики:

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

Команда сообщает серверу, что он связывается не с пользователем, а с обслуживающим сервером (slave). Эта команда позволяет разделить случаи соединения сервера с отдельным пользователем и промежуточными обслуживающими серверами. Это может использоваться для предоставления приоритета запросам от таких клиентов, так как они обслуживают многих пользователей. Это может быть также использовано при возникновении проблем с внутренними ресурсами сервера, когда он может разорвать связи с некоторыми клиентами, сохраняя каналы с обслуживающими серверами. В NNTP-серверах, где приоритетное обслуживание не предусмотрено, команда должна все равно распознаваться и подтверждаться ее получение

Отклик: 202 slave status noted
Ниже приведены примеры (Примеры заимствованы из RFC-0977, Network News Transfer Protocol, B. Kantor, P.Lapsley. (Там их больше)) диалога между клиентом и сервером. Букве C: соответствует клиент, а букве S: - сервер.



Пример 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
(В файле 104 статьи с 10011 по 10125)

(Клиент выбирает статью для чтения)

C: STAT 10110
S: 223 10110 <23445@sdcsvax.ARPA> article retrieved - statistics
only (article 10110 selected, its message-id is

<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.
Пример 2 – абсолютный доступ к статье с помощью команды ARTICLE



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
(Здесь 103 статьи с 402 по 504)

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.
Пример 3 – Команда NEWGROUPS



S: прослушивает порт 119 TCP
C: запрашивает соединения к порту 119 TCP
S: 200 Imaginary Institute News Server ready (posting ok)
(Клиент запрашивает группы новостей после 3-го апреля 1985)

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!
Пример 4 – рассылка новых статей



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 Работа с сервером новостей

NETNEWS (или Usenet, RFC-1036) - всемирная система обмена сообщениями, использующая для этого единый формат. Сообщения рассортированы по темам, которые носят названия newsgroups (группы новостей). Эти сообщения имеют огромный суммарный объем и передаются от ЭВМ к ЭВМ. Они могут содержать текстовую или кодированную двоичную информацию. Сообщение имеет несколько строк заголовка, которые определяют, откуда пришло сообщение, через какие узлы поступило и т.д.

Основные группы новостей, рассылаемые по всему миру, это: 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-команд

! команда Выполнить данную Unix-команду;
! Прервать исполнение rn и уйти в Shell.
Если Usenet доступен с вашего терминала, используйте один из многих программных пакетов, пригодных для чтения новостей. Эти пакеты используют либо доступ к местному серверу, либо работают на основе протокола доступа к новостям (NNTP Network News Transfer Protocol), осуществляя связь с другими ЭВМ сети. Рекомендуется прочесть брошюру "How to become a USENET site", которая посылается периодически в news.answers newsgroup. Она также доступна через анонимное FTP по адресу rtfm.mit.edu в каталоге /pub/usenet/news.answers/site-setup или по почте в mail-server@rtfm.mit.edu со строкой send usenet/news.answers/site-setup.

Существует поддержка 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      
Если выбрать команду g (goto), то предоставляется возможность ввести имя группы новостей, которая вас интересует. Например, выберем группу comp.inforsystems.gopher:

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
Нажимаем <Enter>> и входим в раздел comp.infosystems.gopher. Система выдает список имеющихся документов.

  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
Выбираем сначала пункт 4. Там лежит сообщение:

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

NETFIND представляет собой прикладную программу для работы со справочниками и каталогами. Получив имя человека и некоторые данные о том, где он работает, NETFIND пытается найти его номер телефона, электронный адрес, используя базу данных доменов seed. NETFIND ищет информацию о людях с помощью Интернет-протоколов SMTP и finger. Netfind работает на ЭВМ SUN OS 4.0 или более новых. Могут быть найдены только лица, имеющие доступ к Интернет. Существует возможность работы с NETFIND через электронную почту. Доступ через telnet возможна по адресам (login: 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.
Обычным пользователям наиболее интересны буквы f, m, и n. По умолчанию работают именно эти функции. -d команда инвертирует текущее значение опции, поэтому использование этих трех команд под знаком -d, заблокирует их работу. В качестве имени можно применить фамилию, имя или ID.


При выдаче имени домена или ЭВМ можно выдавать эту информацию без разделительных точек, например, cs colorado edu. NETFIND для входа не требует каких-либо слов-паролей, кроме NETFIND. Воспользуемся услугами сервера nic.uakom.sk:

tn nic.uakom.sk (обращение к серверу в Словакии)
SunOS UNIX (nic) (произошло соединение)
login: netfind (подключаемся к NETFIND-серверу, далее следует текст, выдаваемый сервером)
UAKOM UMB

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 (Запрошена справочная информация)
Help choices: (Справочное меню)

  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)
Enter selection (e.g., 2 0 1)--> 2 0 1

(введен список доменов, где будет проведен поиск)

( 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
Directory: /home/dice/burov Shell: /bin/zsh

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 равна

, откуда следует, что P{x1 2} = P(x2) – P{x1}, а

Так называемый белый шум подчиняется непрерывному нормальному (Гауссову) распределению

, где а – среднее значение x, а s – среднеквадратичное отклонение х от a. В случае шумов среднее значение х с учетом полярности часто принимает нулевое значение (а=0).

В этом случае, если мы хотим знать вероятность того, что амплитуда шумового сигнала лежит в пределах ±

v, то можно воспользоваться выражением

Для вычисления P{x1<x<-x1} обычно используются равенства

и
. Тогда P{x11} =
=
.

Распределение P(x) обычно называется функцией ошибок (erf(x) = -erf(-x)). Полезной с практической точки зрения является вероятность

P{-kss}=Pk(k s) =

, которая позволяет оценить возможность того, что шумовой сигнал превысит некоторый порог, заданный значением k.

Из числа дискретных распределений наиболее часто используемым является распределение Пуассона.

, где n = 0, 1, 2, …; a=mP, m – число испытаний. Распределение Пуассона описывает вероятность процессов, где Pm отношение n/m приближается к значению вероятности P.

Среднее значение x

, а для дискретного распределения
. Среднеквадратичное отклонение s случайной величины х определяется как:
, то же для дискретного распределения
.

Как уже говорилось, во многих случаях шум имеет гауссово распределение с нулевым средним значением амплитуды. В этих случаях среднее значение мощности шумового сигнала равно вариации функции плотности вероятности. В этом случае отношение сигнал-шум будет равно

. Если шум носит чисто тепловой характер, то s2=kTB. В общем случае s2 = EnB [Вт], где полоса B измеряется в Гц, En энергия шума.

Шум определяет вероятность ошибки при передаче сообщения по каналу связи и, в конечном итоге, пропускную способность канала (см. теорему Шеннона; раздел 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])