Re: [Mibble-users] Error in TCP-MIB

[Per Cederberg]

On Thu, 2004-03-04 at 07:04, address@hidden wrote:
> Hi,
> I have the 2.2 version of the Mibble. While working with the TCP-MIB
> I found that the children of tcpConnEntry in the ArrayList are not in
> the order in which they are in MIB. specifically the tcpConnState is
> item number 5 although in the MIB it is the first. I don't know
> whether this is a feature or the expected behaviour but I did not
> face the problem with some other MIBS that I tried.

Ok, after marinating a bit on this I now know why this happens.
A bit simplified one might say that the OID children are added
to the OID parent when the respective symbols are first
referenced in the MIB file.

Here's the relevant portion of the TCP-MIB:

tcpConnEntry OBJECT-TYPE
    SYNTAX      TcpConnEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
            "A conceptual row of the tcpConnTable containing information
            about a particular current TCP connection.  Each row of this
            table is transient, in that it ceases to exist when (or soon
            after) the connection makes the transition to the CLOSED
            state."
    INDEX   { tcpConnLocalAddress,
              tcpConnLocalPort,
              tcpConnRemAddress,
              tcpConnRemPort }
    ::= { tcpConnTable 1 }

TcpConnEntry ::= SEQUENCE {
        tcpConnState          INTEGER,
        tcpConnLocalAddress   IpAddress,
        tcpConnLocalPort      INTEGER,
        tcpConnRemAddress     IpAddress,
        tcpConnRemPort        INTEGER
    }

Looking carefully, you might note that the INDEX clause in 
tcpConEntry lists all the symbols, except tcpConnState...
So when the symbol references are resolved (the MibSymbol
initialize() method called) the symbols listed in the INDEX
clause will have their initialize() methods called before
the tcpConnState symbol. And as the OID children are added
as a part of the initialize() call... well, we end up with
the tcpConnState OID being the last child added in this
case.

You will normally not see this weird behavior as the type
and value definitions are reversed in most other cases. If
you like, I could fix the TCP-MIB in the Mibble distribution
by changing the order of these two statements, making things
work more as expected.

This is not a bug in Mibble 2.2 as the ObjectIdentifierValue
class does not guarantee any kind of ordering between its
children. One might contemplate adding such ordering (based
on the OID value), but if the symbols aren't ordered by OID
in the MIB file it will still have the same strange result... 
Or I might also investigate ways to keep the original MIB
ordering if that is a high priority on your list.

What do you say? Anybody on the list with a strong opinion
on this? I'm tending towards ordering by OID value or MIB
position, but it will of course make things a bit slower
still...

Cheers,

/Per