Читать онлайн «TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security)». Страница 108

 ACCESS read-only

 STATUS mandatory

 DESCRIPTION

  "Общее количество полученных интерфейсом октетов,

   включая символы обрамления кадров."

 :: = { ifEntry 10 }

Масштаб (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 }

Интервалы времени измеряются в Time Ticks, размер которого выражается в сотых долях секунды. Значение TimeTick — неотрицательное целое число в пределах от 1 до 2³²-1. Для переполнения счетчика TimeTick потребуется 497 дней.

SysUptime, измеряющая время от инициализации программного обеспечения агента,— это наиболее часто используемая переменная TimeTick.

sysUpTime OBJECT-TYPE

 SYNTAX TimeTicks

 ACCESS read-only

 STATUS mandatory

 DESCRIPTION

  "Время (в сотых долях секунды) от последней инициализации

  части системы для сетевого управления."

 :: = { system 3 }

OCTET STRING (строки октетов) — это последовательность байт. Почти любые данные можно представить строкой октетов.

Вместо определения новых типов данных в определении MIB применяются текстовые соглашения (textual conventions), позволяющие указать, что информация пакетирована в строки октетов, и описать способ ее вывода пользователям.

Тип данных, определенный через текстовые соглашения, представляется для пересылки неформатированными значениями строки октетов. Однако реальный смысл типа данных определен в описании текстового соглашения. Существуют шаблоны MIB, используемые для создания текстовых соглашений. Приведем пример описания Display String.

DisplayString ::= TEXTUAL-CONVENTION

 DISPLAY-HINT "255a"

 STATUS current

 DESCRIPTION

  "Представление текстовой информации, заимствованное из набора

   символов NVT ASCII, как определено на стр. 4 и 10-11 документа RFC 854."

Следует помнить, что в сообщении значению всегда предшествует идентификатор объекта. Приложение станции управления могло бы использовать определение MIB, которое соответствует такому идентификатору, и применять описание текстового соглашения для выбора варианта отображения, хранения и использования полученного значения строки октетов.

Наряду с языком описания типов данных ASN.1 ISO специфицировала базовые правила кодирования (Basic Encoding Rules — BER), которые используются для кодирования значения данных SNMP при пересылке. Кодирование BER для значений данных имеет вид:

[Идентификатор] [длина содержания] [содержание]

Например, идентификатор X'02 используется для INTEGER, X'04 — для строки октетов, а X'06 — для идентификаторов объектов.

Фактически все сообщение SNMP представляет собой последовательность значений ASN.1, и каждое сообщение полностью кодируется по BER

Наиболее важная часть работы, которая не была реализована в текущей версии SNMP, — это определение новой административной структуры и спецификация условий аутентификации и стандартов шифрования для безопасного удаленного конфигурирования устройств. Однако уже предложены механизмы аутентификации и шифрования трафика на уровне IP (см. главу 24).

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

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

Интеллектуальные системы, подобные маршрутизаторам и хостам, наиболее подходят для самоконтроля. Некоторые интересные результаты были получены при встраивании в системы управляющих приложений и общения с ними через браузеры WWW и протокол HTTP.

Существует длинный и все разрастающийся список RFC, относящихся к SNMP и MIB. Архив RFC в InterNIC содержит самые последние версии этих документов.

Наша другая книга — SNMP: Guide to Network Management — содержит описание концепции и структуры SNMP и детальный разбор некоторых модулей MIB.

Коммуникационные стандарты определяют все правила для обмена информацией в сети. Однако до некоторого момента игнорировалась необходимость стандартизации интерфейса программирования приложений (Application Programming Interface — API). Как же тогда программист должен создавать приложения клиент/сервер, если программы на каждом из компьютеров совершенно различны?

К счастью, большинство реализаций 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, связанные с тем, что коммуникационные службы в операционных системах реализуются по-разному. Детальную информацию по программированию в конкретной системе можно найти в технических описаниях.

Исходный вариант интерфейса 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 применяется несколько дополнительных предварительных вызовов, необходимых для сбора всех сведений перед формированием соединения. Не считая дополнительной работы при запуске, для чтения или записи, в сети применяются те же самые операции.