Re: Generalizing element selection in Wes's -02pre OOPS draft

>>>>> On Fri, 15 Nov 2002 10:19:13 -0500, Robert Moore <[email protected]> said:

Robert> I've inserted <bob> / </bob>'s below.

I've let emacs munge them into Robert>s.

Wes> a) the tables implemented in the agent will be aligned and the
Wes> data returned for the two different requests contained in the
Wes> entire pdu will generate identically ordered responses.  Thus,
Wes> neither the management app nor the agent needs to do alignment
Wes> work.  Joining the two response portions in the PDU are trivial.
Wes> I'd expect this to be the 90-99% case.

Robert> I'm not sure I understand your point here.  If the management
Robert> app isn't *guaranteed* aligned data, won't it have to do the
Robert> alignment step every time, even if the data are in fact
Robert> aligned?

If it's not guaranteed to be aligned, then you only need to check to
see if it is.  If it is going to be aligned 99% of the time, I'd
expect to compare only the indexes across the 2 (say) response parts
and only start to scream if they weren't always equal.  C-ish:

response_piece *p1, *p2;

for(; p1 && p2; p1 = p1->next; p2 = p2->next) {
  if (memcmp(p1->index1, p2->index2) != 0 && ...) {
    /* scream and have to manually align somewhere else, but only for
       p1/p2 greater than what we've already seen */;
  }
}
if (p1 || p2) {
  /* scream again, one had more data than the other.  At least we
     don't have to align.  Just figure out what to do with the other
     data */
}

Point being, the above comparisons should be fast.  Much faster than
assuming that no data is ever aligned and thus forcing sorting and
alignment every time.

Wes> b) The tables implemented in the agent are *not* data aligned (ie,
Wes> the table information are stored independently and in a
Wes> different order).  In this case, I was limiting the sorting that
Wes> the agent had to do.  IE, if the manager needs it combined then
Wes> the manager should do it (insert high-scale database technology
Wes> only available in managers here).  This would generally be the
Wes> minority case, I would think, but I can see situations where
Wes> this could easily happen.

Robert> I was not thinking about this case, but I see your point.
Robert> The question in my mind is just how rare this case will be -
Robert> has anyone actually encountered an agent that works this
Robert> way?

Well, that's what I'd like to ask as well.  However, if no one has
then doing parallel requests as opposed to an in-packet-join won't
hurt you either ;-).  If they have, then my point is valid.

I could easily see someone implementing the storage for the
snmpTargetAddrExtTable table (from the SNMP-COMMUNITY-MIB) in a
separate memory region than the snmpTargetAddrTable it extends.  IE, I
can easily see performance benefits of hashing the augment by address
(since that's how you're going to look stuff up in it a lot of the
time) and the other by index.  Now, I don't know of anyone who's done
this (and I can't raise my hand, because I haven't implemented the
COMMUNITY-MIB).


Wes> 2b) I'll try to publish a new draft shortly after the conference
Wes> with a new ElementSpecifier containing a multiple-subcomponent
Wes> specifier which will actually be something like:

Wes> SEQUENCE {  sub-component OBJECT IDENTIFIER
Wes>             sub-elements  ElementSpecifier }

Robert> <bob>When we first looked at this, we were also thinking along the
Robert> lines of #2b.  The problem we encountered is that while it's clear
Robert> how this works for the request-element-list, it's harder to see how
Robert> it would work for search-criteria.  If you're ANDing, ORing, and
Robert> negating filter elements, it seems like you'd end up with each
Robert> element basically self contained: one table ID plus one column
Robert> ID.

I doubt people are going to AND and OR huge amounts of columns.  But
then, I've been surprised before I suppose.
 
Robert> I also don't understand your comment about regaining
Robert> compression.  In the single-table case, where there's only one
Robert> table OID involved, our proposal is, aside from one extra
Robert> SEQUENCE OF tag, exactly equivalent to yours.

When I looked at it later I realized I misread it.  You're right.

Apparently we'll have to wait for the meeting to hear other opinions
(when I promise to bug people ;-)
-- 
Wes Hardaker
Network Associates Laboratories