Кратко

  • active, notInService и notReady — наблюдаемые состояния агента. createAndGo, createAndWait и destroy — запрашиваемые действия, которые GET никогда не возвращает как сохранённое состояние.
  • Менеджер выбирает индекс и предлагает значения, а MIB и агент решают, допустим ли переход. Поэтому существование, полнота и доступность строки для устройства остаются разными фактами.

Табличный вид был соглашением приложений

Столбцы объектов и индексы экземпляров делали MIB похожей на базу данных. Но RFC 1212 называл таблицы и строки концептуальными. Связь между объектами понимали приложения; сам SNMP не создавал автоматически целую строку и не обеспечивал реляционную целостность.

Для удаления конкретная MIB могла назначить целое значение вроде invalid. SetRequest к ещё не существующим экземплярам мог создать строку, если агент соглашался. DEFVAL заполнял некоторые пропуски. Единого ответа на вопрос, когда набор экземпляров становится пригодной конфигурацией, ещё не было.

При нескольких станциях управления неоднозначность превращалась в конкуренцию. Выбрать индекс, занять его, заполнить обязательные столбцы и включить функцию — четыре разных события. Простое наличие строки не говорило, какое из них состоялось.

RMON показал незавершённую строку

В RMON MIB из RFC 1271 появился прямой предшественник — EntryStatus. Значения createRequest, underCreation, valid и invalid отделяли запрос, строительство, пригодность и удаление. Если несколько менеджеров выбирали один индекс, строку получал первый успешный создатель, а остальные получали ошибку.

OwnerString сообщал, кто создал ресурс, и помогал сотрудничающим системам не мешать друг другу. RFC прямо оговаривал, что это не контроль доступа: несотрудничающий менеджер всё равно мог изменить или удалить запись. Указание происхождения не давало исключительной власти.

Так обозначились два разных утверждения: чего хочет менеджер и что агент способен сообщить о текущем состоянии.

Шесть значений делились на состояния и действия

RFC 1443 стандартизировал RowStatus в SNMPv2. Действующее определение содержится в RFC 2579.

При чтении существующей строки возможны три состояния. active(1) означает, что управляемое устройство может использовать строку. notInService(2) означает, что строка существует и недоступна для использования, хотя информации достаточно для попытки активации. Это не обещание внутренней согласованности, свободных ресурсов или успеха. notReady(3) означает отсутствие необходимых экземпляров столбцов.

Остальные значения — действия записи. createAndGo(4) просит создать и сразу активировать строку. createAndWait(5) просит создать её без ввода в работу. destroy(6) просит удалить все экземпляры концептуальной строки.

GET не возвращает эти три действия. Менеджер также не может установить notReady: нехватку информации определяет агент. Команда и наблюдаемый результат используют одну колонку, но не притворяются одним типом факта.

createAndGo не оставлял нормализованный черновик

Для одношагового создания менеджер выбирает свободный идентификатор экземпляра и отправляет необходимые столбцы вместе с RowStatus=createAndGo. Часть значений агент может добавить по умолчанию.

Если данных достаточно, строка создаётся и сразу читается как active. Если обязательной информации не хватает, операция завершается inconsistentValue, а строка не создаётся. Ошибка не означает, что черновик сохранён. Нужно исправить запрос или использовать поэтапное создание, когда оно поддерживается.

Одна операция имеет строгий смысл именно благодаря этому пределу: создание и активация происходят вместе либо не происходят вовсе.

createAndWait давал незавершённости ограниченное существование

Успешный createAndWait создаёт строку, но не предоставляет её устройству. Если обязательные столбцы отсутствуют, чтение показывает notReady. После их заполнения агент может перевести строку в notInService: сведений достаточно для попытки включения, но работа ещё не началась.

Затем менеджер записывает active. Агент может принять переход или вернуть inconsistentValue из-за значений, ресурсов либо текущего состояния. Готовность к попытке не равна разрешению на работу.

Агент вправе не поддерживать createAndWait, ответить wrongValue и требовать полного создания одним запросом. Он также может отказаться выводить активную строку из работы или удалять её, пока она используется.

Промежуточные строки расходуют ресурсы. Поэтому RFC 2579 требует обнаруживать строки, которые аномально долго остаются notReady или notInService, и удалять их. Срок должен задаваться в DESCRIPTION; если его нет, RFC предлагает около пяти минут с учётом времени человеческого решения. Это рекомендация, а не измерение всех реализаций.

Конкретные правила оставались в описании MIB

RowStatus не решает для всех таблиц, можно ли менять другие столбцы в состоянии active. Где-то изменения разрешены, где-то строку сначала нужно вывести из работы. DESCRIPTION статусного и изменяемых столбцов должна определять обязательные значения и правила изменения.

RFC 4181 закрепил эти требования как практику проектирования. Динамически создаваемая приложениями таблица обычно должна иметь одну колонку RowStatus с доступом read-create. Необходимо описывать сохранность после перезапуска или StorageType, условия самостоятельного создания и удаления строк агентом и ограничения активного состояния.

Общим стал язык переходов, а не политика каждого устройства. Именно текст конкретной MIB наполняет общие состояния предметным смыслом.

Атомарность не выходила за один SetRequest

При создании несколько столбцов и смена RowStatus часто отправляются вместе. RFC 3416 делит обработку SetRequest на две концептуальные фазы: сначала проверяются все variable bindings, затем, при полном успехе, меняются значения. Присваивания происходят так, будто они одновременны относительно других присваиваний в том же запросе.

Если изменение не удаётся, сущность пытается отменить остальные и возвращает commitFailed. Если отменить всё невозможно, возвращается undoFailed. Этот код сам указывает на предел абстракции.

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

Достижением стало честное различие между наличием и работой

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

Видимая строка может быть неполной. Полная строка может оставаться вне работы. Запрос активации может быть отклонён. Даже active не доказывает сохранность после перезапуска, безопасность или прохождение трафика. Состояние полезно именно потому, что не отвечает за следующий слой.

Источники и пределы

RFC 1212 и RFC 1271 описывают ранние соглашения и предшественник RMON. RFC 1443 и RFC 2579 определяют RowStatus. RFC 3416 задаёт границы SetRequest, а RFC 4181 — дисциплину авторов MIB. Источники не измеряют современное распространение, соответствие производителей, безопасность, единый срок очистки или реальный эффект службы. Разделение намерения, готовности и работы — вывод из механизма.