Re: Question on Iterator model without having to setup a linked list

Thanks for the prompt reply and options.

Now let us look at the issue from another way:

People have Emanate in place. Now they want to replace Emanate with Net-Snmp
with performance no worse than Emanate for loosely coupled configuration..
Can anybody share the experience with me?

Regards,

May

On Thu, Jul 2, 2009 at 4:04 AM, Dave Shield <[email protected]>wrote:

> 2009/7/1 May The Dog <[email protected]>:
> > You system supports multiple network management protocols such as SNMP,
> TL1,
> > Q3. CORBA, and has multiple element managers.
>
> That's normal - even if it's only SNMP + cli tools.
>
> >                       Then the container has to
> > be refreshed for any GET and SET request
>
> Not quite.
>
> Looking at this from an SNMP viewpoint, the "container" is simply an
> internal
> cache of information about some underlying subsystem.  (Be this the network
> routing table, list of installed software, crispiness of slices of
> toast, etc, etc)
>
> GET-style requests can be served from this cache, as long as the data is
> regarded as sufficiently accurate - i.e. unlikely to have changed
> significantly
> since the cache was last loaded.   There's an obvious trade-off here - the
> longer the cache timeout, then the more likely there's be some
> inconsistencies
> between this data and the underlying subsystem.
>  The shorter the timeout, then the higher the overheads in reloading the
> cache.
>
>
> A SET request would typically invalidate the cache, so the next GET*
> request
> would trigger a re-load automatically.
>
>
> Extending this to handle multiple management routes, doesn't really change
> the fundamental model.   In terms of monitoring requests, it doesn't
> actually
> matter where these come from - the local cache (or equivalent) would still
> be
> valid.
>   The problems really only arise with respect to active management requests
> (i.e. SET-equivalent).   Again, you have to make the trade-off between
> accuracy
> and efficiency.
>
> One possible other approach would be some form of signalling mechanism,
> so that an SNMP SET request would also be reported to your other management
> services (so that they can also invalidate their local caches).   And
> vice versa.
>   But this would requires cross-configuration between the individual
> management
> systems, so that they know about each other, and how to pass this
> information.
>
>
> Another alternative would be a "semi-cache" approach, where the underlying
> subsystem has some indication of when the basic row data was last changed
> (via *any* management route).  An incoming request would trigger a check of
> this timestamp, to see whether the internal cache was valid or not.
>
>  This might require some instrumentation of each of the management protocol
> modules for this subsystem, but wouldn't require any form of
> cross-communication.
>
> There's also a slight overhead in checking the "external cache flag"
> (rather than
> an internal one),  but that would presumably be quicker than
> re-loading the full data.
>
> Dave
>

------------------------------------------------------------------------------

_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users