2009/4/5 Mark Ellison <[email protected]>: > SNMP requests and re-tries from the same manager have > the same value for the SNMP request ID.
I'm not sure that is necessarily true. >From RFC1905: 4.1. Common Constructs ..... Use of the same request-id on a retransmission of a request allows the response to either the original transmission or the retransmission to satisfy the request. However, in order to calculate the round trip time for transmission and processing of a request-response transaction, the SNMPv2 application needs to use a different request-id value on a retransmitted request. The latter strategy is recommended for use in the majority of situations. Note the last sentence. > I do not know if this value is passed along from > the Net-SNMP master agent to your sub-agent or not. (Dave ??) There are three IDs passed as part of an AgentX request - the sessionID (constant for a given master-subagent connection), the transactionID (constant for the processing of a given SNMP request), and the packetID (used to match AgentX requests and responses). The relevant ID here would seem to be the transactionID, but it's not clear that this is necessarily linked to the requestID from the SNMP request. The specs don't seem to mandate any particular approach to these IDs, but I suspect that SNMP retransmissions would probably result in different AgentX transmissionIDs (regardless of whether the SNMP requestID was the same or not). >> I can block concurrent runs, but sequential runs cause more >> timeouts to occur (along with other problems). The simplest approach to this problem would probably be to cache the results of invoking the subprocess for a short time, and use that cached value to handle any subsequent requests. This should be more-or-less immediate. Dave ------------------------------------------------------------------------------ _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
