Blog

A Sneek Peek at MIB Smithy SDK 4.0

As I mentioned earlier, version 4.0 of MIB Smithy SDK is extremely close to release, now with only 9 cases left open (of which 3 are implemented but just need more QA testing, and one is nearly finished). I thought I’d whet your appetite with a summary of what’s coming, but I also wanted to give fair warning regarding a couple points of compatibility so there are no surprises.

Compatibility issues are one of the main reasons for bumping the major version to 4.0, since Tcl’s “package require” version matching mechanisms make it easy to ensure your scripts pull in a version of a package that is compatible. If you use “package require SmithySDK 3.0” then Tcl will load the latest 3.x version found, but won’t load 4.x, so if there’s any migration you need to do in your scripts then you can change the required version as the migration is done.

The two potential compatibility issues are changes to [officially] supported platforms and in the handling of binary data passed to and returned by the APIs. I’ll get those out of the way first, as they are important, and then tell you about the new enhancements that will also be in the release.

Supported Platform Changes

The minimum version requirements for the Linux, FreeBSD, and Solaris platforms will be changing to something a bit more recent. Current releases are built against Fedora Core 5, FreeBSD 4.3, and Solaris 2.7, which are ancient and long past end of life. I’ve held off requiring newer versions for the next major version because I don’t like to break compatibility in a minor or patch level release. Plus the Solaris development machine, gifted to the company many years ago already many years used, died a couple months ago. That’s why there are no Solaris demos at the moment: I’m still shopping for a replacement; the demo builds expired and can’t be rebuilt at the moment.

We’re currently building 4.0 against FreeBSD 6.2 and Fedora Core 7 (kernel 2.6.23.x), and chances are we are looking at Solaris 10+ (as that’s likely what’s available), so these are likely to be the minimum officially supported versions: as it is, FreeBSD 6.2 and FC7 are both somewhat old. The software will likely run just fine on earlier versions, we just won’t be able to guarantee it since the FC5 and FreeBSD 4.3 VMs, only still around for SDK 3.x builds, will be retired soon after the 4.x release.

There are two upsides here, however, in that (1) I suspect it’s us who’ll be catching up a bit to our user’s platforms, not vise versa; and (2) the last of those 9 cases to be worked on for 4.0 is I’ll be looking at (not promising yet) Linux x86_64 support. I have a VM set up for it already, but I know need to upgrade at least one third-party library before our software will build on it, then I’ll see how it fares against the more than 2000 automated regression test scripts we have for the SDK now (probably 1500 or more written to test the architecture changes in 4.0).

API Changes for Binary Data

The way binary data (OCTET STRING, etc.) is handled is changing. Once upon a time, Tcl didn’t initially have support (or at least good support) for working with binary data at the Tcl level, but it’s now had this for many years (initially with Tcl 8.0, but there were bugs). To work around the limitation, I chose to use a hex format like "0x01:ab" that each of the APIs would accept or return (for example, in request variable bindings or a session’s community string). The SDK would check if a given value had this format and convert it to the equivalent octets, or check if a value to be returned contained anything other than 7-bit printable ASCII and convert it to hex. While this makes such values readable for interactive use, it’s cumbersome for scripts that want to make use of actual binary data. It’s also problematic for using strings that just look like they’re in that format but aren’t intended to be if the APIs go and reinterpret them when you don’t want them to.

And, ever since Tcl’s binary support became stable, I’ve wanted to drop this eventually. Tcl has its own way of specifying binary data in hex ("\x01\xab"), or other formats like unicode, so the SDK having its own hex format is superfluous. But I’ve similarly held off switching to binary for a long time so that it could be done with a major version bump according to package versioning rules. So, instead of using its own hex format, as of 4.0 the APIs will now accept (and return) binary data directly (as Tcl_ByteArrayObjs at Tcl’s C layer). This change affects values in variable bindings, session configuration options (e.g. community strings), values parsed from instance identifiers, etc.

My hope is that switching to binary will have little or no impact on your scripts. Any value you get out of an API call (e.g. get request) and feed back into an API call (e.g. set request) should continue to work, since both sides of the conversion will go away. In general, you should also already be using the [smilib format] command to format SNMP values according to DISPLAY-HINTs when you want to display or print them. If you do, you shouldn’t see much impact there. Strings containing only 7-bit printable ASCII characters should be unaffected because they were not previously converted, and are indistinguishable from byte arrays already. Any impact will largely be confined to values currently hard coded in hex (which are fairly simple to convert to Tcl’s own syntax) or issuing requests in Tcl’s interactive mode (which may print gibberish for binary data).

The [smilib format] command has new capabilities to help as well. Where you now have to specify an OBJECT-TYPE or TEXTUAL-CONVENTION to format a value against, in 4.0 you can specify base types such as "OCTET STRING" to use a default format. For "OCTET STRING", that default format is the same as before, but without the 0x prefix (so, "01:ab" instead of "0x01:ab"). You can use this to, for example, get a guaranteed-printable version of, say, an SNMPv3 User Name (which is typically, but not necessarily, plain text).

Summary of Enhancements

Full release notes will be available with the release, but here’s a quick run down of the new goodies in MIB Smithy SDK 4.0, which will also find their way into MIB Smithy and MIB Views with their next feature releases:

• IPv6 support
• Improved raw binary data support (explained above)
• A new license key format to simplify managing multiple license keys (includes the serial number in plain text, for example)
• A new licensing option (user based, rather than host based)
• Many new MIB and PIB validation rules
• Many clarifications to messages or error levels from existing MIB and PIB validation rules
• More issues in your MIB and PIB modules are automatically corrected for you
• Improved socket error reporting
• Additional properties for working with table definitions smilib

Best of all (for me) is the new architecture will be easier to maintain and extend, and once 4.0 is out I’ll be free to focus all my energy back into new features rather than maintaining two code branches or getting the new architecture to a stable release. With all the QA automation that’s been done for 4.0, it took a long time, but it should be the the most stable dot-zero release of any piece of software I’ve done.