EMPT -- Embedded Message Transport Protocol


EMTP (Embedded Message Transport Protocol) is a protocol targeted towards message exchanges between a small "device" (or embedded system) (e.g. Arduino) and a controlling "computer". The emphasis is on "device", i.e. device with limited computing power (a few MHz) and memory (a few KB) and lacking a networking stack, and "computer", i.e. plug-computer, laptop, desktop, etc., with average or above computing power (at least a few hundred MHz) and memory (at lest a few hundred MB), both linked usually through a serial, RS-232-like, connection.

The main targeted usage of this protocol is control messages, and not data shoveling, where some small latency and small overhead is not an issue, assumptions which are reflected throughout the design.

Thus the terminology for the rest of this proposal is:

The main targeted data link protocol is something resembling a byte stream, for example a serial connection (in the RS-232 sense), which has the following properties:

As such each exchanged packet is embedded into a simple HDLC-like frame, with the observation that the prologue and epilogue bytes are not excluded as valid bytes in the packet. This also implies that the frame parsing is strongly tied to the packet parsing. However the two prologue and epilogue bytes could be used to try to re-synchronize the stream in case of decoding errors.

Of course other data link solutions, like Ethernet, can easily fill the role described above, with only trivial adaptations to the proposed framing.

Transport protocol

The exposed services to the "application" (either the embedded code or the control application) are very similar to the ZeroMQ library, and it's ZMTP protocol, that is:

Flow control

Because the device has limited capabilities, the controller must be throttled not to overburden the device, thus a flow control mechanism is needed. It must be noted that the memory is considered scarcely limited, but not the processing power, thus it is assumed that the device is always able to process protocol related messages (like ping).

Regarding flow control solutions, there are a number of possibilities each with advantages and disadvantages:

Thus the employed solution is based on special packets being exchanged, mandating that the controller must ask permission to send further messages, and the device explicitly permitting them.

On the other hand, the mechanism is asymmetric, that is the device can send messages at will, because the controller is most likely hundreds of times more powerful than the embedded device.

Also the flow control applies only to packets which imply memory consumption, and not to others (like ping) which can be handled immediately.

Moreover the device can impose limits on what the controller is able to send to it (see the limitations structure):



Packet exchanges

Device states

Packet framing

Packet encoding