Re: [squid3-ipv6] NEW INDEXING SCHEMA for Cache-peer

Rafael Martinez Torres wrote:
>> Is there any reason why the PeerIndex is below the field type?
>>
> Sure. You have to keep the lexicographical ordering on OIDS.
>
> RFC1157.txt available under doc/rfc
>
> [...]This naming strategy admits the fullest exploitation of the semantics
> of the GetNextRequest-PDU (see Section 4), because it assigns names
> for related variables so as to be contiguous in the lexicographical
> ordering of all variable names known in the MIB.
>
>> SNMPv2-SMI::enterprises.3495.1.5.1.1.1.1 = INTEGER: 1
>> SNMPv2-SMI::enterprises.3495.1.5.1.1.1.2 = INTEGER: 2
>> SNMPv2-SMI::enterprises.3495.1.5.1.1.2.1 = STRING: "www.google.es"
>> SNMPv2-SMI::enterprises.3495.1.5.1.1.2.2 = STRING: "www.google.es"
>> SNMPv2-SMI::enterprises.3495.1.5.1.1.3.1 = INTEGER: 1
>> SNMPv2-SMI::enterprises.3495.1.5.1.1.3.2 = INTEGER: 1
>> SNMPv2-SMI::enterprises.3495.1.5.1.1.4.1 = STRING: "64.233.183.104"
>> SNMPv2-SMI::enterprises.3495.1.5.1.1.4.2 = STRING: "64.233.183.104"
>>
> This is right, as every OID item is the lexical sucessor of previous
> (i.e. suc(1.1.3.1) = 1.1.3.2
>
>> I kind of expected it to be ordered like this:
>>
>> SNMPv2-SMI::enterprises.3495.1.5.1.1.1.1 = INTEGER: 1
>> SNMPv2-SMI::enterprises.3495.1.5.1.1.2.1 = STRING: "www.google.es"
>> SNMPv2-SMI::enterprises.3495.1.5.1.1.3.1 = INTEGER: 1
>> SNMPv2-SMI::enterprises.3495.1.5.1.1.4.1 = STRING: "64.233.183.104"
>> ...
>> SNMPv2-SMI::enterprises.3495.1.5.1.1.1.2 = INTEGER: 2
>> SNMPv2-SMI::enterprises.3495.1.5.1.1.2.2 = STRING: "www.google.es"
>> SNMPv2-SMI::enterprises.3495.1.5.1.1.3.2 = INTEGER: 1
>> SNMPv2-SMI::enterprises.3495.1.5.1.1.4.2 = STRING: "64.233.183.104"
>> ...
>>
>
> Wrong. This does not keep lexicographical order:
> suc (1.1.4.1) != 1.1.1.2
> (no matter the "...", the same would happen for, let's say,
> suc(1.1.4.15) != 1.1.1.2
>
> If so, you have apply the "-Cc" flag on receiving snmpwalk to ignore order.
> But this is hack, and in fact the SNMP Agent SHOULD return OID's in
> increasing order. As you will see in the further commits, the peer table now
> is ordered by increasing index, (the order of squid.conf file), not as
> previous, where they were unordered. (hence the need to index by IP)
>
> Not a problem if any peer is added or removed in running time. Just
it is
> forbidden by "mib.txt" at least until you reboot the SNMP Agent (the
squid )!

Sorry my bad cut-n-paste. I meant to send:

SNMPv2-SMI::enterprises.3495.1.5.1.1.1.1 = INTEGER: 1
SNMPv2-SMI::enterprises.3495.1.5.1.1.1.2 = STRING: "www.google.es"
SNMPv2-SMI::enterprises.3495.1.5.1.1.1.3 = INTEGER: 1
SNMPv2-SMI::enterprises.3495.1.5.1.1.1.4 = STRING: "64.233.183.104"
...
SNMPv2-SMI::enterprises.3495.1.5.1.1.2.1 = INTEGER: 2
SNMPv2-SMI::enterprises.3495.1.5.1.1.2.2 = STRING: "www.google.es"
SNMPv2-SMI::enterprises.3495.1.5.1.1.2.3 = INTEGER: 1
SNMPv2-SMI::enterprises.3495.1.5.1.1.2.4 = STRING: "64.233.183.104"

Not sure if your answer would be
I understand why it won't work the way I sent first time. Thanks.

>> (but with the last two .detail.peer entries int reversed order
>> .peer.detail)
>>
>> Otherwise it looks good.
>>
>> Amos

Amos
Received on Mon Dec 03 2007 - 23:48:31 MST