Re: OID Compression - implementation experience

[Dave Shield <D.T.Shield@csc.liv.ac.uk>]

Dave>                                                    With
Dave> ODC, there was no way to tell which OIDs would be needed for
Dave> delta calculations, so *all* OIDs had to be saved - possibly
Dave> unnecessarily.  Some form of look-ahead could be used to avoid
Dave> this, but the OPC explicit type tag proved a more useful
Dave> approach.
 
JS> Not sure I fully understand you here. The delta computation is always
JS> relative to the last OID (if I remember correctly) and thus it should
JS> be sufficient to just save the last OID.

You have to save a *maximum* of one OID - yes.
But with the ODC, you *always* have to save this OID.  With OPC you don't.


JS>                                           Can you elaborate on this?

Sure.
Consider an incoming PDU with three varbinds - the first two uncompressed,
the third compressed.

With OPC, the three type tags will be:
	0x06	OBJECT IDENTIFIER
	0x4E	OPC Uncompressed OID
	0x4f	OPC Compressed OID

[OK - my implementation isn't that clever, and would mark both the first
 two as 0x4E - but a different implementation might well generate this]

With ODC, the three type tags will be:
	0x06	OBJECT IDENTIFIER
	0x06	OBJECT IDENTIFIER
	0x2A	ODC Compressed OID

The parser reads in and decodes the first OID.
Does this need to be saved?

With the OPC approach, it's immediately clear that it doesn't.
With the ODC approach, it's not - either we've got to look ahead to the
next varbind type token (which is 0x06, so it turns out that it doesn't)
or we save it anyway (which happens to be unnecessary in this case).

The extreme situation would be a completely non-compressed PDU.
With the OPC approach, none of the OIDs would be saved.
With the ODC approach, they'd all be saved, and never used.


  OK - maybe this isn't a major overhead.
But I hope it explains the point.

Dave