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

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