Re: Table Iterator architecture question

Thanks for the response Robert!

MV

Robert Story wrote:
> On Tue, 09 Aug 2005 14:30:20 -0400 Mike wrote:
> MV> That is, for every iteration through the table rows, the entire row is 
> MV> copied into the agent using snmp_set_var_value; and the entire table is 
> MV> iterated over before the 'handler' method is called and the requested 
> MV> variable is returned.
> 
> MV> So, my questions are:
> MV> 1) why is this table reconstruction necessary for every GETNEXT? (I am 
> MV> assuming it is because the net-snmp core agent needs a snapshot of the 
> MV> table in order to select the right column / row to return; and it makes 
> MV> no assumptions about the table state between GETNEXT calls.)
> 
> Yep. It's meant to deal with unsorted data, and for unsorted data the only
> way to find the 'next' object is to look at all the objects. Caching can
> mitigate this.
> 
> MV> For small tables this is no big deal, but we are going to implement a 
> MV> table with around 20 columns, and there are potentially hundreds of 
> MV> rows: all this copying seems really expensive.
> 
> Later versions should be more efficient with regards to columns, so the number
> of columns is irrelevant.
> 
> MV> 2) Is this how the old UCD API worked? Does the new way solve any 
> MV> errors? Will using the old UCD API be more efficient for large tables?
> 
> No, the old way passed the OID to the handler, which had to deal with get-next
> processing. That's tricky for get-next, and people often didn't understand it,
> or did it wrong.
> 
> Note that there are many new methods that use the new API, iterator is just
> one.
> 
> MV> 3) Is the mib2c 'mib2c.array-user.conf' a more efficient interface for 
> MV> large tables, and are there examples of this pattern?
> 
> Array user assumes the entire table is kept in memory, and is kept sorted. If
> that fits your model, it will be much more efficient.
> 
> MV> 4) Any recommendations for implementing large tables efficiently?
> 
> That depends on the table, where it gets its data, and who 'owns' the data.
> 
> 

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Mike Varley           -= SOMA Networks =-
[email protected]     416-348-1578


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
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