On 19 May 2010 22:01, Boris Zweimueller <boris.zweimuel...@gmail.com> wrote: >> - I don't know how you'd want to handle receiving different answers from >> - the parralel proxied agents, but the above should be a workable >> arrangement. > Answers from different parallel proxies are simply compared. > If they are different this shows some missconfiguration/error.
Surely that would depend on what the MIB ibjects being queried were? If you were querying statistics, then the counts might well be different. (even if only by one or two packets for a heavily loaded system). > Then the device(s) are restarted and reconfigured somethin like that. That would feel overkill for such object counters. Deciding whether or not to restart the device feels more a question for the management console. Which implies that it would need to be able to retrieve the settings for each device individually. So the first thing I'd suggest is that you register the two device subagents independently (perhaps using different contexts). That would then provide the flexibility to manage them independently, as well as the "combined proxy" approach. > I already looked at the current proxy code and made some simple > examples sending the same request multiple times. > > I found that the easiest method would probably be, if > 'doublicate registrations' would be possible My immediate reaction is that this is probably the wrong track to take. The basic model of the agent is that there is one (and only one) handler responsible for any given request. Rather than change this fundamental assumption, you'd probably be better working with a new "combined proxy" handler - similar to the existing one, but splitting the request into multiple destinations, and handling the multiple responses. Either wait for them all to come in before returning a result, or (probably simpler to start with) returning the first result and discarding the rest. But handling this in a single module feels much simpler (and safer!) than fiddling about with the inner workings of the core agent processing. Dave ------------------------------------------------------------------------------ _______________________________________________ Net-snmp-users mailing list Net-snmp-users@lists.sourceforge.net Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users
