COMMS
Template library intended to help with implementation of communication protocols.
|
The COMMS library provides default comms::protocol::ChecksumLayer and comms::protocol::ChecksumPrefixLayer protocol stack layer to handle transport framing checksum. However, they may be insufficient (or incorrect) for some particular use cases. For example the protocol may support multiple checksum algorithms usage of which is determined at runtime. The Implementing New Layers section of the Protocol Stack Definition Tutorial page explains how to define new (custom) protocol layer.
However, since v3.2 COMMS library provides an ability to extend the existing definition of comms::protocol::ChecksumLayer as well as comms::protocol::ChecksumPrefixLayer and customize some bits and pieces. Let's implement the mentioned above example of supporting multiple checksum algorithms.
This tutorial page focuses on the customization of comms::protocol::ChecksumLayer, but all the listed customization points are also applicable to comms::protocol::ChecksumPrefixLayer.
For this example the protocol framing is defined to be
First of all let's define the Common Interface Class, which holds the checksum type information as data member of every message object.
Just to refresh the reader's memory: the usage of COMMS_MSG_TRANSPORT_FIELDS_NAMES() macro for the interface definition will generate transportField_checksumType() convenience member function to access the stored checksum type field.
When implementing the transport framing (protocol stack) the handling of CHECKSUM_TYPE
can be done using regular comms::protocol::TransportValueLayer (see Extra Transport Values).
Now it's time to actually extend the provided definition of the comms::protocol::ChecksumLayer and support usage of multiple checksum algorithms.
The comms::protocol::ChecksumLayer doesn't have any virtual functions and as the result not able to provide any polymorphic behavior. In order to be able to extend its default functionality there is a need to use Curiously Recurring Template Pattern. It is done by passing comms::option::def::ExtendingClass extension option with the type of the layer class being defined to the comms::protocol::ChecksumLayer.
The extending class can customize the default behavior by overriding the listed below functions. They do not necessarily need to be static, accessing inner private state of the layer object is also acceptable.
The newly defined custom protocol stack layer can be used instead of comms::protocol::ChecksumLayer when defining protocol stack (framing) of the protocol. For example: