Re: Tree and node in Net-SNMP source...

[Dave S. <D.T...@cs...>]

>   I'm a bit confused by the tree/node structure.. can anyone of you give
> me some clarification?

I'll try.

When you look at a MIB file, you'll see that it contains a series of
object definitions - one after the other.  Each of these includes a
name, a subidentifier and a parent name (plus lots more stuff that
isn't important right now).

  At this point, there's no real connection between one object and
another - there's just a stream of objects.   In the UCD parser, these
are termed "nodes".


  The next job is to take these nodes, and link them all together by
matching up node names and parent names, to form the overall MIB tree.
When an object is linked in, then the node structure is copied into
an equivalent tree structure, which includes links to the parent,
child and sibling tree structures.

  It would be quite possible to use the same structures for both,
but the CMU codebase that we started from did it this way, and we've
never seen the need to change it.



> What's a peer of a tree?

What I'd call a sibling - the next object in the same "group" as this one.
I.e. with the same prefix OID, but a different final subidentifier.

For example - consider the 'system' object.
The links in the structure representing this object will point as follows:

	child_list	-> sysDescr
	next_peer	-> interfaces
	parent		-> mib-2

Does that help any?


>   Besides, I understand now that when the queried object name (string)
> is of ASCII, it's hashed and searched in the indexed bucket (tree list)
> in the hash table.

Yup - that uses the other link I haven't mentioned above - 'next'.
This forms the list for each hash bucket, and is only used for this
"direct access" approach.


> But how would it do if the queried object string is of OID (1.2.1.. )?

Well, there's an object 'tree_head' which actually points to the 'ccitt(0)'
object.  So the search would go as follows:

	start at tree_head
	search along the 'next_peer' list, to find the subid
		that matches the first element of the OID
	this gives the tree structure 'iso(1)'
	if there are more elements in the OID (which there are)
		follow the 'child_list' link
	this typically gives the tree structure 'org(3)'
	search along the 'next_peer' list, to find the subid
		that matches the first element of the OID
	this (trivially) gives the tree structure 'org(3)'
	if there are more elements in the OID (which there are)
		follow the 'child_list' link
	this typically gives the tree structure 'dod(6)'
		<etc, etc, etc>

Searching for an OID of the form ".iso.org.dod.internet...." would
work similarly (except checking the name, rather than the subid)

Of course, what MIBs have been loaded will affect how far along each
list of siblings the matching object is found.  It might be immediate,
it might be later in the list, or it might not be there at all.
  But that's the basic idea.

OK?

Dave

P.S:  No HTML mail - thanks.