TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security)
Шрифт:
20.10.8 Строки октетов
OCTET STRING (строки октетов) — это последовательность байт. Почти любые данные можно представить строкой октетов.
20.10.9
Вместо определения новых типов данных в определении MIB применяются текстовые соглашения (textual conventions), позволяющие указать, что информация пакетирована в строки октетов, и описать способ ее вывода пользователям.
Тип данных, определенный через текстовые соглашения, представляется для пересылки неформатированными значениями строки октетов. Однако реальный смысл типа данных определен в описании текстового соглашения. Существуют шаблоны MIB, используемые для создания текстовых соглашений. Приведем пример описания Display String.
Следует помнить, что в сообщении значению всегда предшествует идентификатор объекта. Приложение станции управления могло бы использовать определение 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