Кратко
- RFC 1227 позволял локальным процессам регистрировать поддеревья MIB за одним SNMP-агентом; агент делил запрос, обращался к нужным участникам и составлял внешний ответ.
- Приоритет и «эффект монтирования поддерева» определяли, кого спросят. Видимое значение подтверждало локальный выбор, но не постоянное владение, полноту или истинность.
- Распределённый Set сначала собирал согласие или отказ, затем посылал commit либо rollback без финального ответа. Готовность участника не подтверждала применение результата.
Один сетевой адрес скрывал нескольких хранителей
RFC 1227 появился в мае 1991 года из-за разрыва между агентом и живым состоянием служб. Агент мог читать ядро и файлы, но маршрутный процесс хранил собственные данные. SMUX не требовал копировать их в общий склад: процесс подключался локально, регистрировал свой участок MIB и обслуживал относящиеся к нему операции.
Удалённая станция продолжала использовать SNMP из RFC 1157. Агент принимал Get, GetNext или Set, распределял переменные по действующим регистрациям, сопоставлял внутренние ответы и возвращал единый GetResponse. Один внешний собеседник представлял несколько внутренних источников.
Карточка RFC Editor теперь относит документ к Historic, а Datatracker сохраняет его историю. Это статус текста, не доказательство установки. Исторический факт состоит в механизме делегирования, а не в предполагаемом распространении.
Имена объектов происходили из SMI RFC 1155, таблицы SMUX использовали соглашения RFC 1212. Общая грамматика соединяла ветви для читателя, но не объединяла их фактических производителей.
Победившая регистрация была маршрутом, а не правом собственности
Регистрация несла целочисленный приоритет: меньшее число означало более сильную позицию. Несколько процессов могли заявить одно поддерево с разными приоритетами. -1 просил лучшую свободную позицию, однако локальная политика позволяла агенту назначить худшую.
Операции получал только победитель. Кроме того, действовал «эффект монтирования»: если один процесс регистрировал более широкую родительскую ветвь, узкие регистрации внутри неё скрывались от выбора. Они могли оставаться в системе, но запрос к их объектам уходил владельцу широкого монтирования.
Поэтому ответ показывал разрешённый агентом путь в конкретный момент. Он не доказывал отсутствие скрытых процессов, совпадение их значений, первичность победителя или соответствие показания реальному устройству.
Агент должен был защищать области SNMP и SMUX от регистраций и мог запрещать другие ветви по политике реализации. Допуск в пространство имён был локальным отзывным решением, не полномочием менять службу и не титулом на данные.
GetNext заставлял посредника проверять границы
При GetNext каждый процесс вёл себя так, будто содержит всю MIB, и мог вернуть объект за пределами своей ветви. Агент обязан был проверить результат и при выходе из области продолжить поиск у процесса следующего зарегистрированного поддерева.
Последовательность OID на экране не была чтением одной базы. Процесс предлагал следующий объект, агент проверял допустимость и при необходимости переключал источник. Внешняя связность возникала из нескольких локальных решений.
Идентификаторы запросов тоже не давали прямого зеркала. Несколько внутренних PDU, созданных для одного процесса из внешнего запроса, разделяли ID, который не обязан был совпадать с исходным. Без журнала корреляции конечный ответ не раскрывал путь распределения.
Общее согласие предшествовало действию
Если Set затрагивал несколько процессов, агент сначала просил каждого принять или отвергнуть операцию, не выполняя её. Один отказ приводил к rollback для всех, единогласие — к commit.
Но на итоговый SOutPDU процесс не отвечал. noError первой фазы означал приемлемость предложения, а не уже изменённое состояние. Отправленный commit подтверждал решение агента и попытку доставки, но не получение, применение, сохранение или эффект у каждого участника.
Завершение требовало последующего чтения, журнала процесса, состояния оборудования либо независимого наблюдения. Для rollback действовало то же правило. Транзакция координировала решение, но не удостоверяла мир после последнего сообщения.
Строка могла остаться после утраты действительности
MIB SMUX содержала таблицы процессов и деревьев. Перевод строки в invalid не обязывал реализацию удалить её. Станции требовалось читать поле состояния: присутствие было инвентарным фактом, а не признаком текущей работы.
SimpleOpen переносил OID идентичности, описание и пароль; нулевая длина пароля означала отсутствие аутентификации. RFC отдельно не обсуждал безопасность. Идентификатор не устанавливал сам по себе человека, организацию, мандат или достоверность данных.
Отображение на TCP использовало порт 199, а BER само задавало границы объектов. Современный реестр IANA имён служб и портов подтверждает контекст назначения, но не слушатель, программу, соединение или актуальное развёртывание.
RFC 1227 ценен тем, что показал составную природу ровного административного ответа. Внешний ответ, действующая регистрация, значение процесса, решение транзакции и позднее состояние должны оставаться разными доказательствами.
Источники
- RFC 1227 — SNMP MUX Protocol and MIB
- Сведения RFC Editor о RFC 1227
- Запись RFC 1227 в IETF Datatracker
- RFC 1157 — Simple Network Management Protocol
- RFC 1155 — Structure and Identification of Management Information
- RFC 1212 — Concise MIB Definitions
- IANA — Service Name and Transport Protocol Port Number Registry
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров
