Рисунок 4.2.1.5.2. Формат диагностического запроса
Структура пакета-отклика показана на Рисунок 4.2.1.5.3. В зависимости от числа компонентов конфигурации пакет-отклик может иметь различную длину. Поля базового и вспомогательного номера версии характеризуют вариант программы diagnostic responder (например, 1.1). Поле номер диагностического соединителя SPX указывает на соединитель, которому отсылаются все диагностические отклики. Поле счетчик компонентов содержит число описаний компонентов, содержащихся в пакете. Поле тип компонента описывает один из компонентов (или процессов) узла, посылающего отклик. Описание компонента может быть простым и расширенным. Простое описание содержит один байт идентификатора компонента. Расширенное описание компонента включает в себя информацию о маршрутизаторах, файл-серверах и невыделенных IPX/SPX. Первое поле в этом случае представляет собой идентификатор расширенного описания, который характеризует тип компонента:
Рисунок 4.2.3.1. Формат кадра NBFCP
Поле тип содержит код 2, поле длина определяет размер заголовка, если длина=8, имя партнера отсутствует. Поле класс партнера идентифицирует тип системы отправителя (см. таблицу 4.2.3.1).
Рисунок 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 могут заметно загрузить локальную сеть широковещательными сообщениями. По этой причине не следует бездумно множить число таких серверов.
Рисунок 4.2.1.5.1. Формат пакетов “Фрагментированный NDS-запрос/отклик”
Диагностические запросы содержат код 0x0456 в поле соединителя получателя IPX-заголовка. Формат такого запроса показан на Рисунок 4.2.1.5.2. Однобайтовое поле счетчика исключаемых узлов задает число станций, которые могут не присылать отклик. Нуль в этом поле предполагает, что все станции должны откликнуться. Допустимый диапазон значений кодов в этом поле 0 - 79. При широковещательной рассылке запроса можно сделать так, чтобы сервер и определенные клиенты на запрос не реагировали. Для этого их адреса помещаются в поля адресов исключаемых узлов. Число таких исключений может достигать 80.
Рисунок 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-адрес ЭВМ - первичного эталона.
Рисунок 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.
Рисунок 4.2.1.3.2. Формат заголовка NCP-отклика
Поле тип отклика может содержать следующие коды (таблица 4.2.1.3.2):
Рисунок 4.2.1.3.1. Формат заголовка пакета NCP
Поле тип запроса характеризует запрос, передаваемый от клиента к серверу, возможные значения кодов этого поля приведены ниже (таблица 4.2.1.4).
Рисунок 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 представлены сводные данные по основным видам локальных сетей, используемых в настоящее время (список не является полным).
4.2.3 NetBIOS
Протокол NetBIOS был создан для работы в локальных сетях. Система NetBIOS предназначена для персональных ЭВМ типа IBM/PC в качестве интерфейса, независящего от фирмы-производителя. NetBIOS использует в качестве транспортных протоколов TCP и UDP. Описание NetBIOS содержится в документе IBM 6322916 "Technical Reference PC Network" (см. также RFC-1001-2, -1088 и STD-48).
ftp://ietf.org/internet-drafts/draft-ietf-pppext-netbios-fcp-08.txt) создан для использования группой ЭВМ, поддерживает как режим сессий (работа через соединение), так и режим дейтограмм (без установления соединения). 16-и символьные имена объектов в netbios распределяются динамически. netbios имеет собственную dns, которая может взаимодействовать с интернетовской. Имя объекта при работе с NETBIOS не может начинаться с символа *.
Приложения могут через netbios найти нужные им ресурсы, установить связь и послать или получить информацию. NETBIOS использует для службы имен порт - 137, для службы дейтограмм - порт 138, а для сессий - порт 139.
Любая сессия начинается с netbios-запроса, задания ip-адреса и определения tcp-порта удаленного объекта, далее следует обмен NETBIOS-сообщениями, после чего сессия закрывается. Сессия осуществляет обмен информацией между двумя netbios-приложениями. Длина сообщения лежит в пределах от 0 до 131071 байт. Допустимо одновременное осуществление нескольких сессий между двумя объектами.
При организации IP-транспорта через NETBIOS IP-дейтограмма вкладывается в NETBIOS-пакет. Информационный обмен происходит в этом случае без установления связи между объектами. Имена Netbios должны содержать в себе IP-адреса. Так часть NETBIOS-адреса может иметь вид, ip.**.**.**.**, где IP указывает на тип операции (IP через Netbios), а **.**.**.** - ip-адрес. Система netbios имеет собственную систему команд (call, listen, hang up, send, receive, session status, reset, cancel, adapter status, unlink, remote program load) и примитивов для работы с дейтограммами (send datagram, send broadcast datagram, receive datagram, receive broadcast datagram).
Все оконечные узлы netbios делятся на три типа:
Широковещательные ("b") узлы;
узлы точка-точка ("p");
узлы смешанного типа ("m").
IP-адрес может ассоциироваться с одним из указанных типов. B-узлы устанавливают связь со своим партнером посредством широковещательных запросов. P- и M-узлы для этой цели используют netbios сервер имен (NBNS) и сервер распределения дейтограмм (NBDD).
В настоящее время (1985 г) разработана улучшенная версия протокола NETBIOS - NetBeui (NetBios extended user interface). Этот новый протокол используется операционными системами LAN manager, LAN server, Windows for Workgroups и Windows NT, а по своей функции занимает нишу протоколов TCP/IP, охватывая связной, сетевой и транспортный уровни. Здесь стандартизован формат пакетов NetBios, добавлены некоторые новые функции. netbuei базируется на протоколе OSI LLC2, вводит стандарт на формат кадра netbios (NDF) и использует NetBios в качестве интерфейса высокого уровня. Протокол обладает высоким быстродействием и служит для объединения небольших локальных сетей (20-200 ЭВМ) друг с другом или с главной ЭВМ. Этот протокол соответствует связному, сетевому и транспортному уровню модели OSI. В новых версиях NetBuei (3.0 и выше) снято ограничение на число одновременных сессий (254). Среди ограничений NetBuei следует назвать отсутствие внутренней маршрутизации и серьезные ограничения при работе в региональных сетях. По этой причине netbuei рекомендуется для локальных сетей (здесь они предпочтительнее других протоколов), а для внешних связей использовать, например, TCP/IP.
Для подключения терминальной системы к локальной сети или к другой терминальной системе разработан протокол NBFCP (NetBios frames control protocol, код поля протокола = 803F), который в свою очередь базируется на протоколе PPP.
Формат кадра протокола NBFCP показан на Рисунок 4.2.3.1.
Приложение Г. Временная шкала NTP и ее хронометрия
Ниже рассматривается соответствие временной шкалы NTP и UTC (Coordinated Universal Time). Синхронизация часов предполагает их согласование по частоте и времени.
Для синхронизации необходимо уметь сравнить их частоты и показания. Базовыми источниками временных стандартов традиционно являлись периоды движения Земли, Луны и других космических объектов. К сожалению, они не слишком стабильны.
Первичная частота и стандарты времени
Первичными стандартами частоты являются осцилляторы с высокой стабильностью. Такие стандарты используют межуровневые переходы в атомах водорода, цезия и рубидия. В таблице 4.4.15.12 приведены характеристики типичных стандартов времени. Локальные же часы обычно используют некомпенсированные кварцевые генераторы. Такие генераторы не только подвержены дрейфам под действием изменения параметров окружающей среды, но систематически меняют свои свойства со временем (старение).
Даже если кварцевый генератор имеет температурную компенсацию, его частота должна время от времени сравниваться первичным стандартом для обеспечения высокой точности.
Обычно часовые осцилляторы классифицируются по трем параметрам: стабильность, разброс и блуждание. Стабильность определяется систематическими вариациями частоты со временем. Синонимом нестабильности является старение и дрейф. Разброс (называемый также временным дрожанием) характеризует кратковременные случайные вариации частоты с составляющими более 10 Гц, в то время как блуждание характеризует медленные вариации частоты с составляющими менее 10 Гц.
Приложение В. Аутентификация
Требования надежности NTP подобны аналогичным для других протоколов, работающих с большим числом партнеров и служащих для маршрутизации, управления и доступа к файлам. Система должна противостоять случайным ошибкам и злонамеренным действиям.
Механизм управления доступом в NTP отвечает всем базовым требованиям. Различные проверки препятствуют большинству возможных атак, связанных с подменой временных меток.
Однако имеется возможность того, что хакер нарушит процедуру синхронизации путем модификации NTP-сообщений. Для подавления такой возможности нужно привлекать криптографические механизмы аутентификации (в частности сертификаты).
Механизм, который работает на прикладном уровне, служит для того, чтобы исключить неавторизованную модификацию потока сообщений. Это достигается с помощью контрольных крипто-сумм, вычисляемых отправителем и проверяемых получателем. Однако сам протокол NTP не имеет средств для работы с сертификатами и ключами.
Процедура вычисления контрольной крипто-суммы использует алгоритм DES (Data Encryption Standard) [NBS77].
Механизм аутентификации NTP
Когда предполагается использовать аутентификацию, инициализируется ряд переменных, определяющих выбор сертификата, алгоритма шифрования и крипто-ключ и, возможно, другие параметры. Процедуры инициализации и выбора этих переменных не регламентируются протоколом NTP. Набор переменных партнера и пакетов может включать в себя следующие компоненты:
Бит разрешения аутентификации (peer.authenable). Этот бит указывает, что ассоциация работает в режиме аутентификации. Для сконфигурированных партнеров этот бит определяется на фазе инициализации. Для неконфигурированных - этот бит делается равным 1, если приходящее сообщение содержит аутентификатор, в противном случае =0.
Бит аутентификации (peer.authentic). Этот бит указывает, что последнее сообщение, полученное от партнера, было корректно аутентифицировано.
Идентификатор ключа (peer.hostkeyid, peer.peerkeyid, pkt.keyid). Это целое число идентифицирует криптографический ключ, используемый для генерации кода аутентификации сообщения.
Системная переменная peer. hostkeyid используется для активной ассоциации. Переменная peer.peerkeyid инициализируется нулем, когда ассоциация сформирована.
Криптографические ключи (sys.key). Это набор 64-битовых ключей DES, где 7 младших бит каждого октета соответствуют битам 1-7 DES, а старший бит соответствует биту четности 8 (сумма нечетна).
Контрольная крипто-сумма (pkt.check). Крипто-сумма вычисляется процедурой шифрования.
Поле аутентификатора состоит из двух субполей, одно содержит переменную pkt.keyid, а другое переменную pkt.check, вычисленную программой шифрования, вызываемой процедурой передачи протокола NTP, а также программой дешифровки, которая вызывается процедурой приема NTP. Ее присутствия определяется по общей длине UDP-дейтограммы. Для целей аутентификации NTP-сообщение дополняется нулями, для того чтобы сделать ее длину кратной 64 битам. Аутентификатор содержит 96 бит, куда входят 32-битовый идентификатор ключа и 64-битовая крипто-сумма. Дополнительная информация (например, о сертификате и алгоритме шифрования), если необходимо, может быть вставлена между NTP-сообщением и идентификатором ключа. Подобно аутентификатору эта информация не включается в контрольное крипто-суммирование.
Процедуры аутентификации NTP
Когда используется аутентификация для реализации протокола NTP, привлекается две дополнительные процедуры. Одна из них формирует крипто-сумму для передаваемых сообщений, а другая дешифрует и проверяет корректность контрольной суммы получаемых сообщений. Процедуры представляют собой варианты программ, используемых для реализации алгоритма DES и описанных в [NBS80]. На самом деле процедура не связана жестко с алгоритмом DES, а лишь предполагают работу с 64-битовыми блоками данных.
Рисунок 4.1. Примеры сетевых топологий
К первым трем типам топологии относятся 99% всех локальных сетей. Наиболее популярный тип сети – Ethernet, может строиться по схемам 1 и 2. Вариант 1 наиболее дешев, так как требует по одному интерфейсу на машину и не нуждается в каком-либо дополнительном оборудовании. Сети Token Ring и FDDI используют кольцевую топологию (3 на Рисунок 4.1), где каждый узел должен иметь два сетевых интерфейса. Эта топология удобна для оптоволоконных каналов, где сигнал может передаваться только в одном направлении (но при наличии двух колец, как в FDDI, возможна и двунаправленная передача). Нетрудно видеть, что кольцевая топология строится из последовательности соединений точка-точка.
Используется и немалое количество других топологий, которые являются комбинациями уже названных. Примеры таких топологий представлены на Рисунок 4.2.
Вариант А на Рисунок 4.2 представляет собой схему с полным набором связей (все узлы соединены со всеми), такая схема используется только в случае, когда необходимо обеспечить высокую надежность соединений. Эта версия требует для каждого из узлов наличия n-1 интерфейсов при полном числе узлов n. Вариант Б является примером нерегулярной топологии, а вариант В – иерархический случай связи (древовидная топология).
Если топологии на Рисунок 4.1 чаще применимы для локальных сетей, то топологии на Рисунок 4.2 более типичны для региональных и глобальных сетей. Выбор топологии локальной или региональной сети существенно сказывается на ее стоимости и рабочих характеристиках. При этом важной характеристикой при однородной сети является среднее число шагов между узлами d.
6.4.10 Протокол аутентификации Нидхэма-Шредера в случаях симметричной и асимметричной системы шифрования
Протокол Нидхэма-Шрёдера предназначен для решения проблемы аутентификации (см., например, http://www.cs.sunysb.edu/~zhaoming/np.html,
http://dimacs.rutgers.edu/Workshops/Security/program2/boyd/node14.html, а также [1]). Протоколу уже более 20 лет. Алгоритм предназначен для организации аутентифицированного канала между разными ЭВМ в сети по схеме точка-точка. Задача решается с помощью одного или двух серверов аутентификации с использованием общедоступных или общих секретных ключей. Данный протокол предоставляет децентрализованную услугу аутентификации.
Операция аутентификации может охватывать несколько процессов.
Установление виртуального канала двунаправленного обмена сообщениями между двумя субъектами, работающими на разных ЭВМ.
Установление однонаправленного обмена, который, например, имеет место при отправке почты. Здесь ситуация осложняется тем, что субъекты могут не быть одновременно доступны через сеть и не могут непосредственно обмениваться сообщениями.
Коммуникация, при которой источник информации и ее целостность может гарантироваться третей стороной.
Безопасная передача данных по сети, которая сама не является безопасной, предполагает шифрование передаваемой информации. Будем предполагать, что каждая из сторон, участвующих в обмене, способна шифровать и дешифровать данные. Протокол Нидхэма-Шрёдера может работать как для симметричной, так и несимметричной схем шифрования (с общим секретным ключом и с двумя парами ключей, соответственно). Будем также считать, что злоумышленник может подключить свою ЭВМ в любую точку пути, по которому происходит обмен и, таким образом, способен перехватить, воспроизвести или исказить любое сообщение. ЭВМ же субъектов обмена и сервер аутентификации предполагаются защищенными от вторжения.
Сервер аутентификации может предоставить идентификационную информацию, вычисляемую на основе секретного ключа субъекта аутентификации.
Сначала рассмотрим вариант с использованием симметричного шифрования/дешифрования (один ключ).
При схеме шифрования с одним ключом, предполагается, что секретный ключ известен обоим субъектам обмена (А и В) и серверу аутентификации. Инициатором обмена будем считать субъекта А. Сообщения, посылаемые от А к В, могут быть дешифрованы только В и субъект В должен быть уверен, что сообщение пришло именно от А. В начале предположим, что оба субъекта находятся в области действия общего сервера аутентификации (AS). AS знает секретные ключи субъектов А и В (KA и KB, соответственно).
Обмен начинается с того, что субъект А генерирует свой идентификатор IA1, который будет использоваться только один раз. Первое сообщение, посылаемое от A к AS, содержит:
A® AS: |
(A, B, IA1) | (1) |
A® AS: |
(A, B, IA1)KA | (1.1) |
AS® A: |
(IA1, B, CK, {CK, A}KB)KA | (1.2) |
A® B: |
{CK, A}KB | (1.3) |
B® A: |
{IB}CK | (1.4) |
A® B: |
{IB-1}CK | (1.5) |
A® B: |
{CK, A}KB, {IA2}CK | (1.3a) |
B® A: |
{IA2 –1, IB}CK | (1.4a) |
A® AS: |
(A, B) | (2.1) |
AS® A: |
(PKB, B)SKAS | (2.2) |
A® B: |
{IA, A}PKB | (2.3) |
B® AS: |
B, A | (2.4) |
AS® B: |
{PKA, A}SKAS | (2.5) |
B® A: |
{IA, IB}PKA | (2.6) |
A® B: |
{ IB }PKB | (2.7) |
ASA® ASB: |
(CK, A, B, IA1) | (1.11) |
ASB® ASA: |
(CK, A)KB, IA1, A | (1.12) |
A® AS: |
(A, {D}KA) | (3.1) |
AS® A: |
{A, D}KAS | (3.2) |
B® AS: |
B, {A, D}KAS | (3.3) |
AS® B: |
{A, D}KB | 3.4) |
A® B: |
{ (текст)SKA }PKB |
4.2.1.3 Протокол ядра NetWare (NCP)
NCP представляет собой язык общения серверов и клиентов в среде NetWare. NCP-пакет вкладывается в SPX. Рабочие станции передают свои запросы на запись или чтение файлов, на создание очереди заданий, на поиск в дисковых каталогах и т.д. в виде NCP-сообщений. Прежде чем клиент пошлет NCP-запрос, он должен подключиться к серверу и выдать заявку на формирование NCP-канала связи. Сервер в ответ на этот запрос присылает отклик, в котором содержится подтверждение создания такого канала связи, если запрос удовлетворен. Каждому запросу должен соответствовать отклик. Формат NCP-запроса показан на Рисунок 4.2.1.3.1.
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 | Отладочный вывод |
100 | Поясняющий текст |
190 – 199 | Отладочный вывод |
200 | Сервер готов – отправка разрешена |
201 | Сервер готов – отправка запрещена |
400 | Обслуживание прерывается |
500 | Команда не распознана |
501 | Синтаксическая ошибка в команде |
502 | Доступ ограничен или нет разрешения |
503 | Ошибка в программе – команда не выполнена |
Отклик: | 215 далее следует список групп новостей |
Отклик: | 231 далее следует список новых групп |
Отклик: | 230 далее следует список идентификаторов новых статей |
Отклик: | 205 closing connection - goodbye! |
Отклик: | 202 slave status noted |
S: | прослушивает порт 119 TCP |
C: | запрашивает соединения к порту 119 TCP |
S: | 200 wombatvax news server ready - posting ok |
C: | LIST |
S: | 215 далее следует список групп новостей |
S: | net.wombats 00543 00501 y |
S: | net.unix-wizards 10125 10011 y |
S: | net.idiots 00100 00001 n |
S: | . |
C: | GROUP net.unix-wizards |
S: | 211 104 10011 10125 net.unix-wizards group selected |
C: | STAT 10110 |
S: | 223 10110 <23445@sdcsvax.ARPA> article retrieved - statistics |
C: | HEAD |
S: | 221 10110 <23445@sdcsvax.ARPA> article retrieved – далее следует заголовок |
S: | . |
C: | BODY |
S: | 222 10110 <23445@sdcsvax.ARPA> article retrieved – далее следует текст статьи |
S: | . |
C: | NEXT |
S: | 223 10113 <21495@nudebch.uucp> article retrieved - statistics only (статья 10113 является следующей в группе) |
C: | QUIT |
S: | 205 goodbye. |
S: | прослушивает порт 119 TCP |
C: | запрашивает соединения к порту 119 TCP |
S: | 201 UCB-VAX netnews server ready – рассылка запрещена |
C: | GROUP msgs |
S: | 211 103 402 504 msgs Your new group is msgs |
C: | ARTICLE 401 |
S: | 423 No such article in this newsgroup |
C: | ARTICLE 402 |
S: | 220 402 <4105@ucbvax.ARPA> Article retrieved |
S: | Следует заголовок текст и статьи |
S: | . |
C: | HEAD 403 |
S: | 221 403 <3108@mcvax.UUCP> Article retrieved, header follows |
S: | Следует заголовок статьи |
S: | . |
C: | QUIT |
S: | 205 UCB-VAX news server closing connection. Goodbye. |
S: | прослушивает порт 119 TCP |
C: | запрашивает соединения к порту 119 TCP |
S: | 200 Imaginary Institute News Server ready (posting ok) |
C: | NEWGROUPS 850403 020000 |
S: | 231 Далее следуют группы новостей после 03/04/85 02:00:00 follow |
S: | net.music.gdead |
S: | net.games.sources |
S: | . |
C: | GROUP net.music.gdead |
S: | 211 0 1 1 net.music.gdead Newsgroup selected |
C: | QUIT |
S: | 205 Imaginary Institute news server ceasing service. Bye! |
S: | прослушивает порт 119 TCP |
C: | запрашивает соединения к порту 119 TCP |
S: | 200 BANZAIVAX news server ready, рассылка разрешена. |
C: | POST |
S: | 340 Continue posting; Period on a line by itself to end |
C: | Передает статью в формате RFC850 |
C: | . |
S: | 240 Article posted successfully. |
C: | QUIT |
S: | 205 BANZAIVAX closing connection. Goodbye. |
4.2.1 Протоколы Novell (IPX/SPX)
Номер раздела | Название раздела | Объем в страницах | Объем в кбайт |
4.2.1 | Протоколы Novell (IPX/SPX) | 1 | 5 |
4.2.1.1 | IPX-протокол | 4 | 60 |
4.2.1.2 | SPX-протокол | 2 | 26 |
4.2.1.3 | Протокол ядра NetWare (NCP) | 3 | 18 |
4.2.1.4 | Протокол межсетевой передачи больших пакетов (LIP) | 3 | 24 |
4.2.1.5 | Служба каталогов NetWare (NDS) | 4 | 52 |
Межсетевой протокол IPX - (Internetwork Packet eXchange; Novell (См. также А.В.Фролов, Г.В.Фролов, “Локальные сети персональных компьютеров. Использование протоколов IPX, SPX, NETBIOS. Москва, “Диалог-МИФИ”, 1993), [13]) соответствует сетевому уровню модели ISO, до какой-то степени это аналог IP-протокола в Интернет. IPX-протокол может работать совместно с SPX при обеспечении обменов, ориентированных на соединение, где гарантируется доставка информации. IPX произошел от протокола XNS (Xerox Network Services) и имеет ряд уникальных черт. Так IPX может использовать различные схемы инкапсуляции в зависимости от физической сетевой среды. В операционной среде MS-DOS за реализацию протокола IPX отвечает программа IPX.COM или IPXODI.COM. Оболочка же системы NetWare (NETX.COM) и DOS Requester (VLM.COM) используют протокол IPX для пересылки запросов файл-серверу.
Первоначально пакеты Novell инкапсулировались в кадры IEEE 802.3. В настоящее время схема инкапсуляции поддерживает 802.2 и протокол SNAP (Sub-Network Access Protocol).
4.5.7.1 Работа с сервером новостей
Основные группы новостей, рассылаемые по всему миру, это: alt, comp, misc, news, rec, sci, soc и talk. Существует много других базовых категорий новостей, например, bionet, biz, vmsnet, которые рассылаются также повсеместно или в рамках какого-то региона или организации (например, ieee), а также коммерческие (например, clari). Последние категории рассылаются только ограниченно. Сообщения многих Bitnet LISTSERV серверов также рассылаются в виде новостей и относятся к категории bit.
Наиболее важные группы новостей:
Имя группы новостей | Тематика |
alt | Много различных тем (альтернативные группы новостей) |
bionet | Биология |
bit | Многие темы: из подписного листа Bitnet |
biz | Бизнес, маркетинг, реклама |
comp | ЭВМ |
ddn | Defense Data Network (сеть министерства обороны) |
gnu | Фонд общедоступного программного обеспечения, проект GNU |
ieee | Institute of Electrical and Electronics Engineers (Институт инженеров электриков и электронщиков) |
info | Многие темы из листа рассылки Университета Иллинойса |
k12 | От детских садов до высшей школы |
misc | Все, что не попадает в одну из категорий news о самой Usenet |
rec | Хобби, искусство, развлечения, отдых |
sci | Науки всех направлений |
soc | Социальная тематика |
talk | Обсуждение полемических тем |
u3b | AT&T 3B ЭВМ |
vmsnet | DEC VAX/VMS и DECNET системы |
Базовые категории разбиваются на более чем 1200 групп новостей по различным вопросам и темам (от образования для инвалидов до Star Trek и от науки об окружающей среде до политики в странах бывшего Советского Союза).
Качество дискуссий в этой среде не гарантируется. Некоторые группы имеют посредников, которые просматривают сообщения перед рассылкой. Usenet была разработана в 1979 году для системы UNIX. В настоящее время в сети новостей работает несколько тысяч узлов, охватывающих практически весь земной шар.
Новости доступны как через локальный сервер, так и через телефонные коммутируемые сети. Программы для поддержки локального сервера новостей доступны в Интернет, UUCP, EARN/Bitnet и Fidonet. Если вам доступна только электронная почта, тогда для вас Usenet не доступна. Однако, многие группы новостей подключены к спискам почтовой рассылки и вы можете подписаться на них. Для этого шлите запрос в LISTSERV@AMERICAN.EDU со строкой: GET NETGATE GATELIST. Более того, многие документы, которые появляются в новостях, доступны по электронной почте в mail-server@rtfm.mit.edu. Для получения руководства по применению в поле subject напишите HELP.
Команды (базовые), используемые при выборе групп новостей
Основные команды
h | Отобразить справочную информацию; |
q | quit rn (чтение новостей) - прерывание чтения новостей; |
x | quit rn, изменения, внесенные в ваш файл .newsrc, не будут сохранены; |
v | Показать, c какой версией rn вы работаете. RN – прикладная программа, предназначенная для просмотра новостей. |
Space | Выполнение команды по умолчанию; |
y | Чтение текущей группы новостей; |
- | Тоже самое, что и y, но отображает список тем (subjects); |
^N | Переход к следующей нечитанной статье по тому же вопросу; |
k | Пометить как читанные все статьи по текущей теме (subject). |
= | Выдать список всех нечитанных статей; |
число | Переход к статье с данным номером; |
# | Отобразить номер последней статьи. |
n | Переход к следующей группе новостей с нечитанными статьями; |
p | Переход к предшествующей группе с нечитанными статьями; |
P | Назад к следующей статье читанной или не читанной; |
^P | Назад к предыдущей статье по той же теме; |
^ | Переход к первой группе новостей с нечитанными статьями; |
^R | Заново вывести на экран текущую статью; |
$ | Переход в конец списка групп новостей; |
g группа новостей | Переход к заданной группе новостей; |
/эталон | Поиск в прямом направлении группы, содержащей эталон; |
? эталон | Поиск в обратном направлении группы, содержащей эталон; |
/ | Поиск в прямом направлении предшествующего эталона; |
G | Повторить поиск с направлением вперед; |
? | Поиск в обратном направлении предшествующего эталона; |
u | Ликвидация подписки на текущую группу новостей; |
v | Заново вывести на экран текущую статью вместе с заголовком; |
l эталон | Выдача списка неподписанных групп, содержащих эталон; |
L | Выдача состояния групп новостей в файле .newsrc; |
^L | Заново вывести на экран текущую страницу; |
b | Возврат назад на одну страницу; |
c | Пометить все новости в группе как прочитанные; |
A | Пренебречь всеми изменениями в данной группе новостей; |
j | Пометить статью, как прочитанную и перейти в конец; |
^X | Декодировать текущую статью, используя ROT-13; |
X | Декодировать текущую страницу, используя ROT-13; |
r | Послать отклик автору статьи по электронной почте; |
R | То же, что и r, но в ответ включается исходный текст; |
f | Запуск программы Pnews для написания статьи отклика; |
F | То же, что и f, но с включением текста исходной статьи. |
s файл | Запись статьи в файл; |
w файл | То же, что и s, но без записи заголовка. |
! команда | Выполнить данную Unix-команду; |
! | Прервать исполнение rn и уйти в Shell. |
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 |
1825 | 189 comp.graphics.animation Tec | |
1826 | 26 comp.graphics.visualization Inf | |
1827 | 19 comp.groupware Har | |
1828 | 180 comp.groupware.lotus-notes.misc | |
1829 | 151 comp.home.automation | |
1830 | comp.home.misc | |
1831 | 53 comp.human-factors Iss | |
1832 | 27 comp.infosystems Any | |
1833 | comp.infosystems.announce | |
1834 | 130 comp.infosystems.gis All | |
--> | 1835 | 8 comp.infosystems.gopher Dis |
1836 | 1 comp.infosystems.interpedia | |
1837 | comp.infosystems.kiosks | |
1838 | 27 comp.infosystems.wais The | |
1839 | 302 comp.infosystems.www.misc | |
1840 | 16 comp.internet.library Dis |
1 | + 3 mime-type Wolfgang Zekoll | |
2 | + Harmony Binary Release 1.1 Mansuet Gaisbauer | |
3 | + IRD Internet Gopher sites file Fritz Bohnet | |
--> | 4 | + telnet via gopher Monty FullerDC |
5 | + WWW shop of British fine tea from Williamson webmaster@sswi.com | |
6 | + WWW shop of Billy Riggs' sermon tapes webmaster@sswi.com |
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 |
Рисунок 4.2. Различные сетевые топологические схемы
Современные вычислительные системы используют и другие топологии: решетки (А), кубы (В), гипердеревья (Б), гиперкубы и т.д. (см. Рисунок 4.3). Но так как некоторые вычислительные системы (кластеры) базируются на сетевых технологиях, я привожу и такие примеры. В некоторых системах топология может настраиваться на решаемую задачу.
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 минут совпадает результатами современных измерений.
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)
4.5.8.4 Система поиска NETFIND
Адрес сервера | Страна | Адрес сервера | Страна |
archie.ua | Австралия | bruno.cs.colorado.edu | США |
dino.conicit.ve | Венесуэла | ds.internic.net | США |
lincoln.technet.sg | Сингапур | macs.ee.mcgill.ca | Канада |
malloco.ing.puc.cl | Чили | monolith.cc.ic.ac.uk | Англия |
mudhoney.micro.umn.edu | США | netfind.oc.com | США |
netfind.sjsu.edu | США | netfind.icm.edu.pl | Польша |
netfind.vslib.cz | Чехия | nic.nm.kr | Корея |
nic.uakom.sk | Словакия | redmont.cis.uab.edu | США |
netfind.fnet.fr | Франция | eis.calstate.edu | США |
Место работы искомого человека может быть описано ключевыми словами. NETFIND просматривает свою базу данных seed, чтобы найти домен, отвечающий критериям отбора. Список таких доменов отображается и вам предлагается выбрать из них 1-3. Если обнаружено более 100 доменов, NETFIND выдаст имена некоторых из них и предложит повторить поиск с более жесткими условиями. Можно использовать часть названия организации или домена в качестве эталона в процессе поиска. При использовании более чем одного эталона можно применить знак логической операции AND. По завершении поиска или при прерывании его с помощью ^C NETFIND выдает полученный результат. Предлагаются не только данные о домене или организации, но и даты последних входов искомого человека в систему. Обращение к NETFIND имеет формат:
netfind <опции> фамилия (имя) место работы (ключевые слова)
где допустимы следующие опции:
-h |
Указывает NETFIND обойти фазу поиска домена и немедленно начать поиск индивидуальной ЭВМ в базе seed. Эта функция редко используется обычными пользователями |
-s | Исключает применение протокола SMTP при поиске. Поиск происходит немного быстрее, но дает не полную информацию, так как не все ЭВМ пользователей поддерживают протокол finger |
-t | Сообщает сколько случилось таймаутов. -T опция устанавливает время таймаута равным заданному числу секунд, что позволяет увеличить это время в некоторых случаях |
-D | Устанавливает максимальное число доменов, где будет проводиться поиск. По умолчанию эта величина равна 3 (большее значение устанавливать не рекомендуется). Правильный выбор этого числа заметно ускоряет процесс поиска и снижает нагрузку на сеть. |
-H | Устанавливает максимальное число ЭВМ, где будет проводиться поиск. По умолчанию это число равно 50. Устанавливать большую величину не рекомендуется |
-m | Отображает измерительную информацию. Если не указано имя файла, то вывод производится в файл stderr |
-d | Позволяет устанавливать различные классы отладочного вывода (в stderr), используя соответствующую букву для каждого из них, напр. -dsf. Могут использоваться любые комбинации этих букв |
c: | Отображает управляющие сообщения (позволяет контролировать, какой точки достигла программа). |
f: | Отображает сообщения, связанные с finger. |
h: | Выдает список ЭВМ, найденных в базе данных seed. |
m: | Отображает сообщения протокола SMTP. |
n: | Отображает сообщения о неисправности сети. |
r: | Отображает имена ЭВМ из базы seed, которые были отброшены из-за выбора search scope. |
s: | Отображает системные сообщения. |
t: | Отображает сообщения, связанные с thrread. |
tn nic.uakom.sk | (обращение к серверу в Словакии) | |
SunOS UNIX (nic) | (произошло соединение) | |
login: | netfind | (подключаемся к NETFIND-серверу, далее следует текст, выдаваемый сервером) |
Top level choices: | (Выдано базовое меню) |
1. Help (Запрос справочной информации) | |
2. Search (Поиск) | |
3. Seed database lookup (просмотр базы данных SEED) | |
4. Options (Дополнительные возможности) | |
5. Quit (exit server) (Уход из сервера) | |
--> | 1 (Запрошена справочная информация) |
1. Netfind search help (Работа с NETFIND) | |
2. Usage restrictions (Используемые команды) | |
3. Frequently asked questions (Часто задаваемые вопросы) | |
4. For more information (Дополнительная информация) | |
5. Quit menu (back to top level) (Возврат в предыдущее меню) | |
--> | 1 (Запрошена информация о работе с NETFIND) |
NOTE: | Received no responses, and some host or network failures occurred. Maybe try this search again later. (В случае неуспеха можно позднее попытать счастья снова). |
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) |
Login name: burov In real life: | Sergei Bourov | |
(Полное имя: Сергей Буров) | ||
Office: 1d/39, 2081/2747 | Home phone: none |
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) представляет собой селектор, идентифицирующий используемый источник синхронизации. Обычно это указатель на структуру, содержащую переменные партнера. Значение нуль указывает, что в настоящее время источник синхронизации отсутствует.
pkt.peeraddr | /* копирование системных и партнерских переменных */ |
pkt.org | /* копирование временных меток */ |
peer.reach | /* актуализация доступности */ |
if (peer.reach & 6 ? 0) | /* Проверка младших двух бит */ |
if (peer.valid | /* получены корректные данные */ |
peer.valid | /* ничего не слышно */ |
call clock-select; | /* выбираем источник синхронизации */ |
for (all associations) | /* Здесь выполняется управление доступом */ |
call receive-instantiation procedure; | /* создаем ассоциацию */ |
if (pkt.mode = 0) | /* для совместимости со старыми версиями */ |
recv: call packet; | /* обработать пакет */ |
if (valid header) begin | /* если правильный заголовок, актуализовать внутренние часы */ |
xmit: call packet; | /* обработать пакет */ |
peer.hostpoll | /* послать немедленно отклик */ |
pkt: call packet; | /* обработка пакета */ |
if (valid header) begin | /* если заголовок правилен, поправляется показание местных часов */ |
peer.hostpoll | /* послать немедленно отклик */ |
peer.rec | /* забрать полученную временную метку */ |
test1 | /* Тест 1 */ |
test2 | /* Тест 2 */ |
pkt.org | /* потеря временной метки из-за ошибки */ |
test1; | /* ложные тесты */ |
peer.org | /* актуализация исходной временной метки */ |
peer.peerpoll | /* скорректировать период рассылки */ |
test6 2 and | /* Тест 6 */ |
test7 | /* Тест 7 */ |
test8 | /* Тест 8 */ |
peer.leap < pkt.leap; | /* Копирование переменных пакета */ |
if (valid data) call clock-filter(q, d, e); | /* обработка данных */ |
call clock-select; | /* Выбор базовых часов */ |
l andistance(peer); | /* обновление системных переменных */ |
if (local clock reset) begin | /* если сброс, очистить системные переменные */ |
sys.peer | /* если нет, то подстроить локальные часы */ |
peer.leap | /* Копирование переменных */ |
call clock-filter({sys.clock - peer.rec, 0, 1 | /* образец процесса */ |
call clockupdate; | /* коррекция локальных часов */ |
sys.leap 2; | /* копирование переменных */ |
for (all configured peers) | /* создание конфигурированных ассоциаций */ |
peer.peeraddr | /* копирование переменных */ |
call clear; | /* инициализация ассоциации */ |
peer.config | /* Копирование переменных */ |
if (pkt.mode = 3) | /* Определение режима */ |
call clear; | /* инициализация ассоциации */ |
peer.config | /* копирование переменных */ |
call clear; | /* инициализация ассоциации */ |
peer.org | /* пометка неопределенных временных меток */ |
peer.reach | /* сброс переменных состояния */ |
peer.filter | /* все ступени */ |
{peer.hostpoll | /* первичная установка периода рассылки */ |
call clock-select; | /* Выбор эталонных часов */ |
temp | /* определение периода запросов ЭВМ */ |
if (peer.timer = 0) | /* сброс таймера партнера */ |
Таблица 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, драйвера локальной сети, программы маршрутизатора или файлового сервера).
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 |
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 |
Таблица 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 |
Таблица 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 октетов.
Таблица 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(x) обычно называется функцией ошибок (erf(x) = -erf(-x)). Полезной с практической точки зрения является вероятность
P{-kss}=Pk(k s) =
, которая позволяет оценить возможность того, что шумовой сигнал превысит некоторый порог, заданный значением k.Из числа дискретных распределений наиболее часто используемым является распределение Пуассона.
Среднее значение 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])