SNMP 请求是否连续 - 它们是否有可能成倍数到达
Are SNMP request sequential - are there chances they it can arrive in multiples
我正在写一个SNMP代理，打算写一个代理来一个一个地处理SNMP请求。意味着当请求到达端口 161 时 - 在响应/超时完成之前不会接受任何进一步的请求。
我不确定有多少 SNMP 客户端 - 但 SNMP 请求是同步和顺序的 - 有什么方法可以让它们一次批量进入？
Get请求是一个请求一个OID，GetBulk请求可以在一个请求中请求多个OID。 SNMP 客户端还可以使用异步模式以最小间隔发送多个请求并等待回复。
由于网络延迟和等价路由，数据包也可能乱序到达。您可以尝试使用 snmpget、snmpgetbulk、snmpbulkwalk 发送请求，并使用 tcpdump 查看网络上的内容。
因此，一般来说，您的代理必须准备好接受突发请求。
为简单起见，如果请求率较低并且您的代理可以足够快地回复，您可以使用一对一处理。在这种情况下，一些请求可能会失败，但客户端可以重试请求并最终得到代理的回复。
我认为 SNMP 查询很容易爆发，因为多个独立的经理轮询您的代理 and/or 如果您的代理响应速度不够快，单个焦虑的经理会重试相同的命令。
在编写 SNMP 代理时，另一个考虑因素是估计代理收集所需数据以响应的最大 可能时间。我相信它不应该是 OID-average，而是 OID-maximum。换句话说，如果您的代理服务 100 个 OID，其中查询一个 "slow" OID 将导致整个（同步）代理阻塞并停止为其他代理服务——这种情况可能会破坏您的代理在网络上的可信度...
最重要的是，如果您碰巧连续多次遇到相同的慢速 OID（例如管理器重试），延迟可能会累积，从而有效地阻止其他查询。
总结一下：我认为高性能的SNMP代理应该具备以下特点：
- 支持海量并发SNMP命令处理
- 具有收集托管对象数据的非阻塞数据源访问权限
- 采用某种形式的缓存或速率限制来保护计算量大的数据源免受自大的 SNMP 管理器的影响
另一方面，如果您的 SNMP 代理在低功耗硬件上提供一小段静态数据，并且您不希望有太多管理人员与您交谈，也许您可以使用简单的同步SNMP 代理...
顺便说一句，BSD 套接字接口会保存一个未处理的 UDP 数据包队列，这样您的代理就有机会赶上来。
你的问题的前提是有缺陷的，因为没有 "coming in bulk at a single time" 的概念——无论接收到构成 SNMP 数据包的 UDP 数据报的顺序如何，也无论两者之间的持续时间有多长您的网络接口收到每个数据包后，您的操作系统将按接收顺序向您显示 SNMP 数据包。您有一个监听端口和一个读取缓冲区。所以这种同步性已经是网络数据处理的工作方式，您不必担心。
不过我要说的是，如果您在处理 SNMP 请求时正在等待某些资源可用（正如您使用单词 "timeout" 所暗示的那样），您可能应该继续并开始同时处理您的其他未决 SNMP 请求，否则您将面临整个堆栈停止运行的风险。让经理等待某个未知的持续时间来等待对请求 B 的响应是不公平的，因为其他经理发出的请求 A 正在经历服务延迟。话虽这么说，您可能确实希望对一次可以处理的请求数量设置一些上限，以防止潜在的 DDoSsing——选择这个值只能由您根据用例和生态系统的知识来完成。
我正在写一个SNMP代理，打算写一个代理来一个一个地处理SNMP请求。意味着当请求到达端口 161 时 - 在响应/超时完成之前不会接受任何进一步的请求。
我不确定有多少 SNMP 客户端 - 但 SNMP 请求是同步和顺序的 - 有什么方法可以让它们一次批量进入？
Get请求是一个请求一个OID，GetBulk请求可以在一个请求中请求多个OID。 SNMP 客户端还可以使用异步模式以最小间隔发送多个请求并等待回复。 由于网络延迟和等价路由，数据包也可能乱序到达。您可以尝试使用 snmpget、snmpgetbulk、snmpbulkwalk 发送请求，并使用 tcpdump 查看网络上的内容。
因此，一般来说，您的代理必须准备好接受突发请求。 为简单起见，如果请求率较低并且您的代理可以足够快地回复，您可以使用一对一处理。在这种情况下，一些请求可能会失败，但客户端可以重试请求并最终得到代理的回复。
我认为 SNMP 查询很容易爆发，因为多个独立的经理轮询您的代理 and/or 如果您的代理响应速度不够快，单个焦虑的经理会重试相同的命令。
在编写 SNMP 代理时，另一个考虑因素是估计代理收集所需数据以响应的最大 可能时间。我相信它不应该是 OID-average，而是 OID-maximum。换句话说，如果您的代理服务 100 个 OID，其中查询一个 "slow" OID 将导致整个（同步）代理阻塞并停止为其他代理服务——这种情况可能会破坏您的代理在网络上的可信度...
最重要的是，如果您碰巧连续多次遇到相同的慢速 OID（例如管理器重试），延迟可能会累积，从而有效地阻止其他查询。
总结一下：我认为高性能的SNMP代理应该具备以下特点：
- 支持海量并发SNMP命令处理
- 具有收集托管对象数据的非阻塞数据源访问权限
- 采用某种形式的缓存或速率限制来保护计算量大的数据源免受自大的 SNMP 管理器的影响
另一方面，如果您的 SNMP 代理在低功耗硬件上提供一小段静态数据，并且您不希望有太多管理人员与您交谈，也许您可以使用简单的同步SNMP 代理...
顺便说一句，BSD 套接字接口会保存一个未处理的 UDP 数据包队列，这样您的代理就有机会赶上来。
你的问题的前提是有缺陷的，因为没有 "coming in bulk at a single time" 的概念——无论接收到构成 SNMP 数据包的 UDP 数据报的顺序如何，也无论两者之间的持续时间有多长您的网络接口收到每个数据包后，您的操作系统将按接收顺序向您显示 SNMP 数据包。您有一个监听端口和一个读取缓冲区。所以这种同步性已经是网络数据处理的工作方式，您不必担心。
不过我要说的是，如果您在处理 SNMP 请求时正在等待某些资源可用（正如您使用单词 "timeout" 所暗示的那样），您可能应该继续并开始同时处理您的其他未决 SNMP 请求，否则您将面临整个堆栈停止运行的风险。让经理等待某个未知的持续时间来等待对请求 B 的响应是不公平的，因为其他经理发出的请求 A 正在经历服务延迟。话虽这么说，您可能确实希望对一次可以处理的请求数量设置一些上限，以防止潜在的 DDoSsing——选择这个值只能由您根据用例和生态系统的知识来完成。