Thank you for taking the time to look through this. Be fore warned that the C++ code involved is more than a little esoteric. The project provided is from Microsoft Visual Studio 10 C++.

The first thing to understand is that most of the work is done in templates, frequently selected and manipulated via member pointers. This tends to make the details hard for a novice programmer to dig through. Unfortunately, this complexity was the price that had to be paid to make a lot of routine software operations simple.

If you actually start working with the code, understand, this is intended as a working example. It is not presented as an perfect implementation.

For example, in the main function (see KISS.cpp), messages are instantiated, loaded with data, sent and received. This is simple and visible. The fact that the set and get functions were auto generated by the templates invoked in the message structure is irrelevant. Further, the calls to MsgQueue send() and recv() transfer the message instances provided as an argument. The serializers and deserializers embedded in the templates used to create the messages is, again, transparent.

Currently (Nov., 2014) the project supports revisions of the message structures and five alternative serializers/deserializers. The first thing learned is that while in places the code should execute correctly, the compiler threw type errors on code that would never be run if the offending types were actually called out. These errors did not show up in the original code from Software Revision Control. It was only when the calling sequences for the serializer was added that the problem manifested.

The problem was overcome by adding an integer argument to the Element Leaf Previous version (ElLeafPrev) template. This integer was used to select a #if/#else/#end if set that was appropriate to the revision tree. Similarly, it was also found that an additional set of templates were needed for elements that were structures or classes.

As a result, the naming conventions have change a little. Templates used for simple types are ElLeafCur or ElLeafPrev. While the templates used for structures are ElNodeCur and ElNodePrev. These have been broken out into separate files to hold down the clutter.

The structures used in a message must contain the extra logic to allow the serializers to recursively walk through the structure and its constituent elements.

Another thing to note is that some data elements were added just to disrupt the flow of the data. For example the Position structure has a one byte char element as the first element. This serves no practical purpose except to shift the other elements off of normal word boundaries. This isn't a wise or good practice, but it does help identify and correct problems in the serializers.

Currently, the model supports three serializers:

1) By reference. Within the same memory space, this provides the fastest means of transferring messages.,

2) Native is designed to be a minimal CPU cost, and maintains conventional word boundaries. It is intended for use through shared memory crossing between processes using different memory spaces.

3) Loose has started packing to byte boundaries, while keeping the native data types. It is a compromise between CPU and network bandwidth. The resulting messages are suitable for high speed network connections.

4) Tight takes the data elements, scales them and then packs to the bit level, a smaller message at the expense of additional CPU cycles.

5) XML translation. It is large, slow and unwieldy, but it works.

A standard header structure has been included to allow the identification and sorting of message types. The message type have been broken into a one byte Group (zero is the command and control group, and '<' is an XML message), one byte message number, one byte version number, and a one byte serializer identifier. Other data elements will be added as needed.

Future enhancements:

1) Start fleshing out the MsgQueue class to initialize better, support message selectivity and version control, then support multiple comm link types.

2) Get a basic Manager and Secretary working.

3) Add the logic to the Manager to automatically handle routing through a broker/router/gateway.

Long range enhancements:

1) Currently beyond the scope of this exercise, is to add message variants. In this case, there is a message base class that covers most of a message's data elements. Derived classes of this message add specialization for selected interfaces.

More background will be provided as the model matures.