Кратко

  • RowStatus различает читаемые состояния active, notInService, notReady и доступные только для записи действия createAndGo, createAndWait, destroy. Запрос менеджера не выдаётся за уже установленный агентом факт.
  • createAndWait позволяет сохранить и продолжить неполную строку, но не даёт исключительной резервации и не гарантирует активацию. Одновременность и откат относятся к одному SetRequest, а не ко всей серии обменов или группе устройств.

У незавершённой работы должен быть срок

Пошаговое создание удобно, пока создавшая строку программа остаётся на связи. Она может добавить недостающие значения и включить запись. Но процесс способен завершиться аварийно, сеть — оборваться, а оператор — уйти. Тогда строка остаётся на устройстве, не участвует в его работе и всё же занимает память, место в таблице или ресурс измерения.

RFC 2579 требует от агента обнаруживать концептуальные строки, которые аномально долго находятся в notReady или notInService, и удалять их. Срок должна задавать DESCRIPTION конкретного столбца состояния. Лишь если там срока нет, документ предлагает примерно пять минут.

Это не универсальный пятиминутный таймер. Для редкого ресурса разумен короткий возврат, а законная процедура с внешним согласованием может требовать большего окна. Правило также относится к ранее активной строке, которую надолго оставили в notInService, а не только к свежей неудачной попытке.

Агент хранит локальный ресурс и потому получает последнее средство освобождения, когда удалённый участник перестал продвигаться. Но он не знает намерений исчезнувшего менеджера. Срок соединяет возможность восстановления с обязанностью не держать ресурс бесконечно.

Почему написанное действие нельзя прочитать как состояние

RowStatus задаёт шесть числовых значений, но не называет все их состояниями. active и notInService разрешено читать и писать. notReady разрешено читать, но запрещено писать. createAndGo, createAndWait и destroy — действия: их пишут, но никогда не получают при чтении.

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

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

Так интерфейс не смешивает намерение и наблюдение. Написанное действие говорит, чего хотел менеджер. Прочитанное состояние говорит, что агент способен подтвердить после обработки.

Маленькая операция столкнулась с составной строкой

SNMP в RFC 1157 от мая 1990 года представлял функции агента как чтение и изменение именованных переменных. Это позволяло одному небольшому набору операций работать с разными устройствами и не превращало протокол в перечень специальных команд.

Концептуальная строка связывает несколько переменных. Ей может понадобиться свободный индекс, обязательные столбцы без значений по умолчанию, согласованность между полями и выделение ограниченных ресурсов. Одну таблицу могут менять несколько менеджеров, а экземпляр может создать само устройство.

Способность записать значения не отвечала на вопросы времени: как другим увидеть неполную строку, когда она становится пригодной и кто разбирает остаток оборванной операции.

В RMON эта проблема возникла как практическая. RFC 1271, опубликованный в ноябре 1991 года, описывал управляющие таблицы, где несколько менеджеров делили ресурсы мониторинга. EntryStatus включал createRequest, underCreation, valid и invalid. Документ обсуждал коллизии, сбой менеджера, брошенные записи и строку владельца, помогавшую участникам понять происхождение конфигурации.

Строка владельца не была аутентификацией и не давала полномочий. Она обеспечивала контекст. Более важным стало признание, что создание длится, может быть замечено другими и может остаться незавершённым.

В апреле 1993 года RFC 1443 обобщил эту практику как текстовое соглашение RowStatus и прямо назвал RMON EntryStatus её источником. RFC 1903 пересмотрел соглашение в 1996 году. RFC 2579 1999 года закрепил детальный цикл, используемый здесь. Частный опыт управляющих таблиц превратился в повторно используемую модель жизненного цикла.

Сначала создать, затем выяснить недостающее

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

Промежуточный результат хранится в управляемом интерфейсе, а не только в памяти клиента. После перезапуска оператор может заново прочитать строку. Другой менеджер отличит полное отсутствие от уже созданного, но незаконченного объекта. Незавершённость становится проверяемым фактом.

Переход к notInService всё же не является одобрением. При записи active агент может вернуть inconsistentValue. Все поля способны присутствовать и при этом противоречить друг другу. Может не хватить ресурса или измениться локальное условие. Готовность к попытке уже, чем готовность к работе.

Политика редактирования остаётся за определением конкретной таблицы. DESCRIPTION сообщает, какие столбцы меняются в active, требуется ли сначала notInService и может ли агент отказать в приостановке. Общее соглашение не делает все таблицы одинаковыми.

Ожидание не превращается в блокировку

Созданная менеджером строка может выглядеть как занятое им место. RFC 2579 предупреждает об обратном: между createAndWait и последующей записью active управляемое устройство способно создать собственный экземпляр. Тогда значения в агенте могут вытеснить то, что передал менеджер.

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

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

Если нужен исторический след удаления, система аудита должна отдельно сохранить запрос, предыдущее состояние и основание. RowStatus описывает текущий жизненный цикл, но не заменяет журнал событий.

Где заканчивается атомарность SetRequest

Запись нескольких столбцов в одной операции получает более сильную локальную границу. RFC 3416 требует сначала проверить variable bindings SetRequest. Присваивания в этом же запросе происходят так, как если бы они были одновременными относительно друг друга. Если после проверок одно присваивание не удаётся, остальные отменяются и возвращается commitFailed. Если отменить всё невозможно, возвращается undoFailed.

Менеджер может объединить несколько значений и действие создания в одном PDU. Но createAndWait, последующее чтение, дополнение столбцов и запрос active — это несколько уже завершённых операций. Между ними может случиться отказ или конкурентная запись. Откат последнего запроса не отменяет более ранние ответы.

Та же граница исключает распределённую интерпретацию. «Как если бы одновременно» относится к присваиваниям одного SetRequest у одного отвечающего агента. Это не commit для нескольких маршрутизаторов или других устройств.

undoFailed дополнительно запрещает считать, будто любая ошибка оставляет всё без изменений. Когда агент не смог полностью вернуть состояние, менеджеру следует перечитать реальные значения и заниматься восстановлением на основании наблюдения.

Ограниченная ответственность вместо общего обещания

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

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

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

Источники