Porting Mibble to C#

[nickaein]

First of all, thank you for providing such great library.

There has been some attempts to port Mibble to other languages (e.g. MibbleSharp as a C# port). As they might have become outdated by now, I am considering to port Mibble again in C#.

I wanted to make sure I have got a good understanding of the Mibble code structure before starting such task.

1. Apparently the only part of codes that are auto-generated are located at src/java/net/percederberg/mibble/asn1. Is that right?

2. Honestly, I didn't expected the scale of hand-written code for an SNMP MIB parser. I expected it to be mostly auto-generated code for the grammar plus a light wrapper that loads the MIB file and feeds the parser to build the AST tree and then a minimal API for querying that tree.

I've looked through code and understood some parts of it (e.g. mechanism for importing multiple MIBs) but I'm sure I am missing many other functionalities. For instance, why types such as MibValueSymbol.java needs to be implemented? Do they abstract away the underlying AST parser nodes? And MibAnalyzer.java is one of the main places where these abstraction is carried out?

3. There are two options for porting the auto-generated code:

• Porting the auto-generated codes directly to target language
• Rebuilding the lexer/parser/etc in the target language using the source asn1.grammar file.

Do you have any comments on these? The second approach could generate a more optimal and "native" code. However, I am not sure if the generated code is compatible with the rest of codes.

[cederberg]

Porting to C# is a major undertaking.

Mibble uses Grammatica, which already has C# support (although quite dated at this time). So generating an ASN.1 parser from the grammar file is trivial.

But Mibble does a lot more. In particular it contains built-in Java code to translate the SNMP macros to usable objects. A raw parse tree isn't very "semantic", as relations between objects tend to be too flexible and too loosely linked. So Mibble "resolves" all the named type references to their actual types (in multiple steps and across imported MIBs), while also preserving enough information to separate types that resolve to same basic type (e.g. 32 bit integer). See Gauge and Counter as examples.

To your questions:

1. Yes, this is correct. The auto-generated classes contain a clear notice in the file header.

2. It's complicated to explain all of Mibble in a single comment. And some of it would be different had I written the code today. MibValueSymbol vs MibTypeSymbol was an attempt at separating the two types of symbols in a MIB (types and values). Typical example of too much OO design. The real action is found in the subclasses of MibType, MibValue and SnmpMibValue.

3. Grammatica easily re-generates a C# parser for you. But it is the MibAnalyzer that does all the fun stuff. Like pruning the parse tree from all intermediary nodes and building up the data object hierarchy accessed via Mib. And then two steps of symbol name resolving kicks in after all the MIB files are parsed.

[nickaein]

Thanks for the thorough explanation!

I was looking for a solution to parse MIB files in C# and was in dilemma of

1. Generating a AST.1 parser in C# working around that
2. Porting the Mibble to C#

I can see now that option 2 could worth it.

I will take my chances with Sharpen to port and see how well that works.

Cheers,