SBE

What tool should be used to generate stubs from  schema?

MarketFactory recommends using the RealLogic SBETool. It should be noted that we use v1.25.1 to avoid a bug in the CME ilink3 schema that is revealed with later versions of the tool, but clients are free to use later versions.

The breaking change was introduced in SBE Tool v1.25.2, as described in RealLogic issues #889 and #917:  because it is impossible to specify a character value of 0x00 in a valid XML document, the proposed solution, such as it is, is to convince CME to remove the null_value="0" attribute from the specification of charNULL in their schema.  This may take a while.

Why does the wire representation of a message appear different to that defined in the schema?

When directly inspecting "on-the-wire" representations of char datatypes - including enumerations which may take numeric values - be aware that these are subject to UTF-8 encoding, and you may be inspecting the decimal code of the given character.

...

• 49 - '1' - Buy
• 55 - '2' - Sell
• 55 - '7' - TwoWay

When I parse/write a string from/to a fixed length SBE field, how do I determine/signal where to truncate?

The string with either be null-terminated or will be of the size of the fixed length field. So if the string is smaller than the field length; it will end with a \0. If the string is the same length as the field length then there is no terminator. 
When writing you do not have to ensure the remainder of the array is all \0 values - although that would work. The string just needs to be terminated with a single \0; or if the string is exactly as large as the field length - you don't need to do anything.

The server expects string fields to be terminated with a \0.

Why is there no checksum in the SBE messages?

It's worth remembering that the FIX protocol checksum is at the application level. The underlying TCP transport also incorporates it's own CRC and checksum checks.

...

In addition, SBE is a performance-oriented wire protocol. If checksums are included as for the FIX protocol, application-level checksum computation becomes a significant component of the overall cost.

Is there no way to define groups once rather than have them repeatedly defined for each message type that uses them in the SBE schema? 

Unlike FIXML, there is no definition of an attributeGroup component that is defined once and referenced multiple times (e.g. in a complexType). In SBE each group has to be an explicit component of it's parent group or message. To minimise the amount of 'duplicate' code, there are two broad avenues to consider:

Schema change

There is a way to aggregate multiple fields together as a composite datatype (and a composite may itself reference other composite types), so using our NoHops group as an example, in theory we could move to something like:

...

In short, this is not a fruitful path. The "SBE way" is for each message to be self-contained, if you didn't want to rely on the generated stubs (with the duplicate types etc), then at a slight performance hit, the typical alternative would be to use an on-the-fly decoder model, which requires usage of the SBE intermediate representation to process each message in a more generic manner.

Smarter stub generation

MarketFactory has thought about creating a 'smarter' stub generator that would identify common groups, types etc  and generate a more optimised set of getter/setter etc primitives. This is conceptually doable and probably much more in line with what you're looking for, although this work is not currently planned.

Session Handling

If I wanted to keep a message store so I could resend messages, what technique would MF recommend?

A typical technique is to write every outgoing message to a memory mapped file at the same time as sending it down the TCP socket, for possible retrieval later. The file could be persisted to disk periodically if there was a need to keep it longer term.
If you don't need to replay messages to the venue, then just storing the sequence number is good enough.