Являются ли SNMP-запросы последовательными - есть ли вероятность, что они могут быть получены кратно
Я пишу агент SNMP и планирую написать агент для обработки запроса SNMP один за другим. Означает, что, когда запрос поступает на порт 161 - не будет принимать дальнейшие запросы до тех пор, пока не завершится ответ / тайм-аут.
Я не уверен во многих клиентах SNMP - но действительно ли запрос SNMP является синхронизированным и последовательным - есть ли способ, которым они могут прийти навалом за один раз?
3 ответа
Я думаю, что SNMP-запросы могут легко прийти к пакету из-за того, что несколько независимых менеджеров опрашивают вашего агента и / или один тревожный менеджер повторяет одну и ту же команду, если ваш агент не достаточно быстр, чтобы ответить.
Когда дело доходит до написания SNMP-агентов, другим соображением будет оценка максимально возможного времени, необходимого агенту для сбора необходимых данных для ответа. Я считаю, что это должен быть не средний OID, а максимальный OID. Другими словами, если ваш агент обслуживает 100 OID, из которых запрос одного "медленного" OID приведет к тому, что весь (синхронный) агент заблокирует и перестанет обслуживать других - эта ситуация может подорвать доверие к вашему агенту в сети.,
Вдобавок к этому, если вам случится нажать один и тот же медленный OID несколько раз подряд (например, повторные попытки менеджера), задержка может накапливаться, эффективно блокируя другие запросы.
Подводя итог: я думаю, что высокопроизводительный агент SNMP должен иметь следующие особенности:
- Поддержка массовой одновременной обработки команд SNMP
- Наличие неблокирующего доступа к источникам данных для сбора данных управляемых объектов
- Наличие некоторой формы кэширования или ограничения скорости для защиты вычислительно дорогих источников данных от дерзких SNMP-менеджеров
С другой стороны, если ваш агент SNMP обслуживает небольшой фрагмент статических данных на оборудовании с низким энергопотреблением, и вы не ожидаете, что слишком много менеджеров когда-либо будут с вами разговаривать, возможно, вам не помешает упрощенный синхронный агент SNMP...
Кстати, интерфейс сокетов BSD будет содержать очередь необработанных пакетов UDP, чтобы у вашего агента был шанс наверстать упущенное.
Суть вашего вопроса ошибочна, так как отсутствует концепция "массового поступления за один раз" - независимо от того, в каком порядке принимаются дейтаграммы UDP, составляющие пакет SNMP, и независимо от того, сколько времени проходит между При получении каждого пакета вашим сетевым интерфейсом ваша операционная система будет последовательно представлять вам пакеты SNMP в порядке поступления. У вас есть один порт прослушивания и один буфер чтения. Таким образом, эта синхронность уже используется для обработки сетевых данных, и вам не стоит об этом беспокоиться.
Тем не менее, я бы сказал, что если вы ожидаете, что какой-то ресурс станет доступным во время обработки запроса SNMP (как предполагает использование вами слова "тайм-аут"), вам, вероятно, следует включить и начать обработку других ожидающих запросов SNMP в тем временем, или вы рискуете, что весь ваш стек остановится. Несправедливо заставлять менеджера ждать какой-то неизвестной продолжительности ответа на запрос B только потому, что какой-то другой менеджер сделал запрос A, который испытывает задержку в обслуживании. Тем не менее, вы, вероятно, хотите, чтобы какой-то верхний предел количества запросов можно было обслужить одновременно, чтобы предотвратить потенциальный DDoSsing - выбор этого значения может быть сделан только вами, с вашим знанием варианта использования и экосистемы.
Запрос на получение - это один OID на запрос, запрос GetBulk может запрашивать несколько OID в одном запросе. Также SNMP-клиент может использовать асинхронный режим, отправляя несколько запросов с минимальными интервалами и ожидая ответов. Пакеты также могут поступать вне очереди из-за сетевых задержек и маршрутов с одинаковой стоимостью. Вы можете поэкспериментировать с отправкой запросов с помощью snmpget, snmpgetbulk, snmpbulkwalk и использовать tcpdump, чтобы увидеть, что находится на проводе.
Так что, в общем, ваш агент должен быть готов к приему пакетов запросов. Для простоты, если частота запросов низкая и ваш агент может ответить достаточно быстро, вы можете использовать обработку один за другим. В этом случае некоторые из запросов могут потерпеть неудачу, но клиенты могут повторить запрос и, наконец, получить ответ от агента.