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

[Per Cederberg]

My second post from monday morning doesn't seem to have
reached the list, so I'll repost it below for anyone
interested. I might also point out that the numerical OID 
ordering discussed below has been implemented in version
2.3 and actually turned out to make Mibble a little bit
faster... :-)

Cheers,

/Per

-----Forwarded Message-----
> From: Per Cederberg <address@hidden>
> To: "Announcements, support, and forum for Mibble users" <address@hidden>
> Subject: Re: [Mibble-users] Error in TCP-MIB
> Date: Mon, 08 Mar 2004 10:51:38 +0100
> 
> 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