Re: timeout problems
- From: Simon Leinen <simon@xxxxxxxxxxxxxxxx>
- Date: Tue, 05 Sep 2006 10:47:33 +0200
king writes:
I am developing an snmp subagent. It takes around 30 secs to compute
a set of values to service getnext request for a table. The values
cannot be precalculated.
1. So can I return the next OID as the same OID to make the client
repeatedly come back till the values are computed?
I would be careful with that. Some SNMP clients ("Command Generators"
or whatever the Politically Correct name is) may implement some
loop-prevention mechanism and refuse get-next responses that don't
indicate forward progress.
In fact I would recommend such loop-prevention mechanisms, because
there have been agents with buggy get-next implementations that would
cause harmless table traversal operations to loop indefinitely.
Other than that, your suggestion seems like a neat hack to allow an
agent (oops, "Command Responder") to tell a manager that it needs more
time. But it would have to be elevated to a generally accepted
convention ("standard"), and I'm a bit skeptical for that.
An even neater hack would be to improve your agent so that table
access is less slow. 30 seconds response time will make network
managers unhappy even if they get intermediate "hourglass icon"
reports-that-something-is-happening.
You say that the values cannot be calculated in advance; the trick
would be to somehow precompute the *path* to the first/next values in
the table. I'm assuming that your problem is that the "natural"
ordering of your managed data doesn't match the lexicographic ordering
in your MIB's indexing structure well.
This is a common problem - I would be interested in how the writers of
SNMP agents and SNMP agent toolkits handle this in general. (It's
been about 13 years that I wrote SNMP agent code, and I remember
spending lots of time on this.)
2. If a client timeouts and resends a query, how is the duplicate
requests and responses handled?
Some clients will use a different request ID (or maybe even a
different UDP source port) for the resent queries, and will ignore
late responses to the original query that is being retried.
Other clients will use the same request ID for retries, and will
accept a late-arriving response to the original query packet.
(I'm not 100% sure what the SNMP standards say. I'm pretty sure that
at some point, they did allow both types of behavior. Maybe this got
tightened up, but I'm pretty sure that both behaviors have been
implemented and deployed.)
--
Simon.
.
- References:
- timeout problems
- From: king
- timeout problems
- Prev by Date: Re: IPV6-TC needs MODULE-IDENTITY?
- Next by Date: Some queries about Traps
- Previous by thread: timeout problems
- Next by thread: Re: timeout problems
- Index(es):
Relevant Pages
|
