Machinetalk explained Part 2: Middleware Requirements

This blog post is a continuation of my Machinetalk explained series describing the concepts and ideas behind the Machinetalk middleware.

This part is about the requirements of the Machinetalk middleware and their fulfillment through the used technologies.

To understand the concepts outlined in this article I recommend you first to read Part 1: Introduction before continuing reading this article.

If you are more interested in the technical details behind Machinetalk you can skip ahead to Part 3: Technologies.

Machinetalk Requirements

The requirements of Machinetalk provide interesting information to the background of Machinetalk.

The requirements primarily derive from the limitations discovered during the utilization of the NML middleware formerly used in Machinekit. In this place, I have to thank Michael Haberler for the original write-up of these requirements in the LinuxCNC mailing list.

However, if you are interested in the use of Machinetalk outside of Machinekit, you will very likely find common patterns which apply to your project as well.

Additionally, each listed requirement also includes the fulfillment in Machinetalk.

Common requirements

The common requirements apply to all parts of Machinetalk.

• Language Neutrality

  The middleware shall have language bindings for at least C, C++ and Python. Ideally, the middleware shall be completely language neutral.

  All libraries and technologies used in the Machinetalk middleware are language neutral. Additionally, Machinetalk-GSL provides a platform independent way of implementing language bindings.

• Fitness for Real-Time Environment

  The middleware shall run on all supported real-time Linux flavors. However, execution of the transport messaging stack within real-time threads is not required. Messages will are passed from user space to real-time components using the ring buffer API of the HAL. It is required that serialized messages are interpretable in real-time threads of any flavor.

  Machinetalk is not a jack of all trades device. Instead, it clearly defines its real-time limitations.

  All Machinetalk dependencies are running on the supported real-time Linux kernels. ZeroMQ and the service discovery libraries are not usable within the real-time threads. However, Protobuf serialized messages passed to real-time threads are decodable using the plain C Protobuf implementation nanopb.

  The middleware does not require real-time capabilities since HAL processes all real-time tasks in Machinekit.

  Applications which require hard real-time communication between two devices shall use a real-time capable Fieldbus instead.

• Transparent Message Passing

  Intermediary components shall not be required to understand message contents beyond what is required by the semantics of involved components.

  ZeroMQ supports transparent message passing. Transparent message passing means that ZeroMQ does not need to understand the contents of a message to forward it.

  Furthermore, all Machinetalk serializes all messages using a union container message, including a Machinetalk type field. Using this type field, Machinetalk can distinguish between different message types without processing the rest of the message.

• Freedom of Arbitrary Limits

  Message encoding, as well as message transport, shall not constrain the use of the middleware by setting hard limits, for example, to message size.

  Neither Protobuf nor ZeroMQ introduces any arbitrary limits.

  The maximum size of Protobuf encoded messages can be set at compile time.

  ZeroMQ does not limit message the size at all. The only constraint is the memory size on the application computer.

• Based on Widely Adopted Solutions

  The middleware shall only use libraries, standards, and tools, that already have been widely adopted by the open source community and industry to keep long-term maintenance and support costs low.

  ZeroMQ is one of the market leaders in messaging middleware solutions [zotpress items="JSVMV3UC" style="IEEE"]. Protobuf is used in many Google products and widely adopted by the open source community. DNS-SD over mDNS is an Internet Engineering Task Force (IETF) standard [zotpress items="JSVMV3UC,UJIB3NH5" style="IEEE"] and is used in many products such as network printers and media streaming devices.

Requirements of the Messaging Stack

The following requirements apply to the messaging stack of the middleware.

• Blocking and Non-Blocking Message Handling

  The transport library shall be able to send and receive messages in a blocking as well as a non-blocking fashion without resorting to cyclically polling for new messages to be available.

  ZeroMQ supports blocking and non-blocking message handling either by including it into an event loop or by using file descriptors.

• Start-up sequence

  The middleware shall only use libraries, standards, and tools, that already have been widely adopted by the open source community and industry to keep long-term maintenance and support costs low.

  ZeroMQ supports any start-up sequence. However, depending on the used network pattern messages might either be queued or dropped if no remote peer is available.

• Idempotent Connect and Reconnect

  Components shall be able to connect and reconnect to a running system without requiring a full restart of the real-time stack. This requirement supposes that the transport stack provides measures to detect disconnects and connects to nodes to allow state synchronization of components if necessary.

  ZeroMQ does partially support idempotent connect and reconnect. It automatically handles reconnects of sockets However, ZeroMQ does not provide measures to detect, disconnects and reconnects of peers. Therefore, Machinetalk uses an extra heartbeat and connection state detection mechanism.

• Decentralized Messaging

  The messaging stack shall not require a broker for communication. The messaging stack shall be able to operate completely decentralized and using a peer-to-peer pattern.

  ZeroMQ as a messaging library does support different messaging patterns. ZeroMQ does not need a broker for messaging, but if necessary building a broker is possible. Moreover, ZeroMQ supports one-to-one, one-to-many and many-to-many communication. Furthermore, ZeroMQ supports forwarding and routing of messages.

• Minimal Configuration Requirements

  A minimal or no configuration effort shall be required to use the messaging transport. Automatic detection of matching peers is desirable.

  ZeroMQ uses an API similar to POSIX sockets. To connect to a remote peer, only a service Uniform Resource Identifier (URI) is required. Machinetalk services additionally need the service type to detect matching peers using the DNS-SD over mDNS service discovery mechanism. The Machinekit UUID serves as a unique identifier for a Machinekit instance.

• Authentification and Encryption

  The messaging transport shall support secure authentication and encryption.

  ZeroMQ does support authentication and encryption using CurveZMQ.

  However, Machinetalk currently does not support CurveZMQ. The implementation is scheduled for a later release.

Requirements for Message Serialization

The following requirements are related to the message serialization part of the Machinetalk middleware.

• Interface Definition Language Based Encoding

  The message serialization library shall use an Interface Definition Language (IDL) for describing the message structure. It shall be possible to access and manipulate messages in any supported programming language without resorting to manual coding.

  Protobuf uses its own IDL for describing messages. Based on .proto IDL files the Protobuf compiler generates native programming language classes for Java, C ++ and Python. Third-party implementations provide support for additional languages.

• Message Introspection

  All required language bindings shall support message introspection. Message introspection allows an application to analyze the type and properties of messages at run-time. This feature decreases the cost of implementing functions to handle new and unknown messages.

  Protobuf does only partially support introspection. Protobuf encoded messages are per default not self-descriptive. Therefore, components using a particular Protobuf message need a local copy of the message definition to decode and encode the message correctly. To support introspection with Protobuf, Machinetalk uses a single top level union container message shared by all Machinetalk messages. Therefore, components can decode any Machinetalk message, providing they have the Machinetalk message descriptions. This feature is for example used by the Webtalk broker.

• Versioning Support

  The serialization library shall support versioning of messages to allow backward compatibility to older messages. No recompilation of all associated components shall be necessary if a message definition changes. Unsupported message content shall automatically be skipped.

  Protobuf achieves support for backwards-compatibility of messages by numbering all message fields. The Protobuf decoder ignores fields unknown by old components. In case an old message is received by a component which has a new message definition, default values are used to complete all new message fields. To fully achieve backward compatibility, some rules described in “Thrift: The Missing Guide” [zotpress items="AU4R25X5" style="IEEE"] need to be followed.

• Architecture Independence

  The serialization and message format shall be completely architecture independent. The serialization library shall automatically handle byte order and floating point representation without manual coding.

  Protobuf supports a set of data types independent of byte order and representation. Furthermore, the generated Protobuf classes handle serialization and deserialization in a platform and architecture independent way.

• Web Browser Support

  The serialization format shall be suitable to be used in combination with web technologies. Automatic conversion to web formats such as JSON shall be possible. No manual translation of messages shall be required. A message serialization format capable of introspection does automatically fulfill this requirement.

  Webtalk bridges the ZeroMQ sockets to WebSockets and uses the introspection support of Protobuf to convert messages to the JSON format. As an alternative, the WebVCP uses Protobuf.js for serializing directly in the web browser.

Coming up

Since this blog post became very long, I decided to dedicate another post solely to the technologies used in Machinetalk. So the next article in this series will be about the technologies employed in Machinetalk, namely ZeroMQ, Protobuf and DNS-SD over mDNS.

The fourth blog article will be about HAL remote and the last blog post will be about modeling and code generation for the Machinetalk language bindings.

I would very much appreciate any feedback and comments.

Your
Machine Koder