Efficient sorting of SNMP oids

[B Maqueira]

Peter Corlett wrote:
> On 31 Oct 2009, at 16:03, B Maqueira wrote:
>> I need to sort eficiently a large array (~9000) of SNMP OIDs.
>>
>> I am currently trying the following code:
>>
>> my @sorted_oids = map { $_->[0] }
>>                                  sort { $a->[1] cmp $b->[1] }
>>                                     map { [$_, pack('w*', split(/\./,
>> $_))]  } @oids;
>>
>> But this fails since it outputs 1.3.6.1.4.1.2333.3.2.61001.1.10 before
>> than 1.3.6.1.4.1.2333.3.2.8080.1.1.1
>>
>> Any ideas?
>
> That's because "w" format is a BER encoding, and this does not map
> integers into strings such that ordering is maintained. For example,
> 16383 encodes to "\xff\x7f", but 16384 encodes to "\x81\x80\x00" which
> string-sorts earlier.
>
> Relatively few encodings *do* maintain that ordering. Big-endian
> fixed-width does. So I'd use "N*" instead in your pack format, mainly
> because I'm not entirely sure whether the components of SNMP OIDs can
> ever be greater than 65535 and thus whether I could thus get away with
> "n*" to halve the storage required.
>
>
Thank you all for the advice.

Using Sort::Key::OID or sort::maker would have been great, except that
we need to deploy the script to a rather large number of servers and it
is traditionally long and painful to get modules approved and deployed
in our machines.

Using "N*" certainly did the trick. I guess I must read the RFC for OIDs
+ work out what is the range covered using N*. But right now I have some
oids looking like BASE.8129.1.10.1402551989 and
BASE.61003.1.10.2138245292 that seem to be working fine.

Again, huge thanks to you all for your replies!