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

[May T. D. <may...@gm...>]

Or do we have an older version of net-snmp, which ONLY does the following
for  the table get-first/get-next in the user hook:

1) increment the index
2) for the get-next, when the index is out of order, it stops.

In another word,  the index is stored in datebase or another data manager.
Net-snmp only act as a front end for the SNMP protocol.

Regards,

May




On Thu, Jul 2, 2009 at 1:57 PM, May The Dog <may...@gm...> wrote:

> 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 <D.T...@li...>wrote:
>
>> 2009/7/1 May The Dog <may...@gm...>:
>> > 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
>>
>
>