Сидни Фейт - TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Общее количество полученных интерфейсом октетов,
включая символы обрамления кадров."
:: = { ifEntry 10 }
20.10.6 Масштаб
Масштаб (gauge) — это целое число, которое ведет себя по-разному. Значения масштаба увеличиваются и уменьшаются. Масштабы используются для количественного описания, например длины очереди. Иногда значение масштаба растет, а иногда уменьшается.
32-разрядный масштаб может увеличиваться до 2³²-1 (4 294 967 295). Если измеряемая величина превышает масштаб, то она фиксируется в этом максимуме, пока значение снова не уменьшится (см. рис. 20.14).
Рис. 20.14. Поведение значения масштаба
Пример переменной масштаба:
ifOutQLen OBJECT-TYPE
SYNTAX Gauge
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Длина выходной очереди пакетов
(в пакетах)."
::= { ifEntry 21 }
20.10.7 TimeTicks
Интервалы времени измеряются в Time Ticks, размер которого выражается в сотых долях секунды. Значение TimeTick — неотрицательное целое число в пределах от 1 до 2³²-1. Для переполнения счетчика TimeTick потребуется 497 дней.
SysUptime, измеряющая время от инициализации программного обеспечения агента,— это наиболее часто используемая переменная TimeTick.
sysUpTime OBJECT-TYPE
SYNTAX TimeTicks
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Время (в сотых долях секунды) от последней инициализации
части системы для сетевого управления."
:: = { system 3 }
20.10.8 Строки октетов
OCTET STRING (строки октетов) — это последовательность байт. Почти любые данные можно представить строкой октетов.
20.10.9 Текстовые соглашения
Вместо определения новых типов данных в определении MIB применяются текстовые соглашения (textual conventions), позволяющие указать, что информация пакетирована в строки октетов, и описать способ ее вывода пользователям.
Тип данных, определенный через текстовые соглашения, представляется для пересылки неформатированными значениями строки октетов. Однако реальный смысл типа данных определен в описании текстового соглашения. Существуют шаблоны MIB, используемые для создания текстовых соглашений. Приведем пример описания Display String.
DisplayString ::= TEXTUAL-CONVENTION
DISPLAY-HINT "255a"
STATUS current
DESCRIPTION
"Представление текстовой информации, заимствованное из набора
символов NVT ASCII, как определено на стр. 4 и 10-11 документа RFC 854."
Следует помнить, что в сообщении значению всегда предшествует идентификатор объекта. Приложение станции управления могло бы использовать определение MIB, которое соответствует такому идентификатору, и применять описание текстового соглашения для выбора варианта отображения, хранения и использования полученного значения строки октетов.
20.10.10 Копирование типов данных в BER
Наряду с языком описания типов данных ASN.1 ISO специфицировала базовые правила кодирования (Basic Encoding Rules — BER), которые используются для кодирования значения данных SNMP при пересылке. Кодирование BER для значений данных имеет вид:
[Идентификатор] [длина содержания] [содержание]
Например, идентификатор X'02 используется для INTEGER, X'04 — для строки октетов, а X'06 — для идентификаторов объектов.
Фактически все сообщение SNMP представляет собой последовательность значений ASN.1, и каждое сообщение полностью кодируется по BER
20.11 Что дальше?
Наиболее важная часть работы, которая не была реализована в текущей версии SNMP, — это определение новой административной структуры и спецификация условий аутентификации и стандартов шифрования для безопасного удаленного конфигурирования устройств. Однако уже предложены механизмы аутентификации и шифрования трафика на уровне IP (см. главу 24).
Разработчики и авторы стандартов ведут активные поиски возможностей расширения и улучшения определений MIB, в результате чего в сетях в изобилии стала доступна сырая управляющая информация.
Необходимы хорошие приложения, чтобы эффективно использовать информацию SNMP для обнаружения сетевых проблем и долгосрочного планирования необходимой емкости ресурсов. Производители оборудования нуждаются в стандартизированных прикладных комплектах программных инструментов разработки, чтобы можно было перемещать полученные новые средства между различными станциями управления.
Интеллектуальные системы, подобные маршрутизаторам и хостам, наиболее подходят для самоконтроля. Некоторые интересные результаты были получены при встраивании в системы управляющих приложений и общения с ними через браузеры WWW и протокол HTTP.
20.12 Дополнительная литература
Существует длинный и все разрастающийся список RFC, относящихся к SNMP и MIB. Архив RFC в InterNIC содержит самые последние версии этих документов.
Наша другая книга — SNMP: Guide to Network Management — содержит описание концепции и структуры SNMP и детальный разбор некоторых модулей MIB.
Глава 21
Программный интерфейс socket
21.1 Введение
Коммуникационные стандарты определяют все правила для обмена информацией в сети. Однако до некоторого момента игнорировалась необходимость стандартизации интерфейса программирования приложений (Application Programming Interface — API). Как же тогда программист должен создавать приложения клиент/сервер, если программы на каждом из компьютеров совершенно различны?
21.1.1 Программный интерфейс Berkeley
К счастью, большинство реализаций TCP/IP обеспечивает программный интерфейс, следующий очень простой модели программного интерфейса socket, который впервые был предложен в 1982 г. в версии 4.1c операционной системы Unix университета Беркли (Berkeley Software Distribution — BSD). Co временем в исходный интерфейс было внесено несколько усовершенствований.
Программный интерфейс socket разрабатывался для применения с различными коммуникационными протоколами, а не только для TCP/IP. Однако, когда была закончена спецификация транспортного уровня OSI, стало ясно, что этот интерфейс не согласуется с требованиями OSI.
В 1986 г. компания AT&T предложила спецификацию протокола интерфейса транспортного уровня (Transport Layer Interface — TLI) для операционной системы Unix System V. Интерфейс TLI мог применяться для транспортного уровня OSI, TCP и других протоколов.
Еще одним важным событием в истории socket стал программный интерфейс socket для Windows (WinSock), позволивший приложениям Windows функционировать поверх стеков TCP/IP, созданных разными производителями. В Windows 95 обеспечивается поддержка многопротокольного интерфейса.
Интерфейс socket стал стандартом де-факто благодаря широкому распространению и универсальности доступа. В этой главе мы рассмотрим общие принципы работы этого интерфейса. На компьютерах могут существовать незначительные отличия в API, связанные с тем, что коммуникационные службы в операционных системах реализуются по-разному. Детальную информацию по программированию в конкретной системе можно найти в технических описаниях.
21.1.2 Ориентация на Unix
Исходный вариант интерфейса socket был разработан для Unix. Архитектура этой операционной системы позволяет единообразно обращаться к файлам, терминалам и вводу/выводу. Операции с файлами предполагают использование одного из следующих вызовов:
descriptor = open(filename, readwritemode)
read(descriptor, buffer, length)
write(descriptor, buffer, length)
close(descriptor)
Когда программа открывает файл, вызов создает в памяти область, называемую управляющим блоком файла (file control block) и содержащую сведения о данном файле (например, имя, атрибуты и место размещения).
Вызов возвращает небольшое целое число, именуемое дескриптором файла (file descriptor). Дескриптор используется в программе для идентификации файла в последующих операциях. При чтении или записи в файле специальный указатель из дескриптора отслеживает текущее положение внутри файла
Похожие методы используются в socket для TCP/IP. Главным отличием между программным интерфейсом socket и файловой системой Unix является то, что в socket применяется несколько дополнительных предварительных вызовов, необходимых для сбора всех сведений перед формированием соединения. Не считая дополнительной работы при запуске, для чтения или записи, в сети применяются те же самые операции.
