SIMPL is as SIMPL does

Lead Image © Dietmar Hoepfl,


The low-priced, small-footprint Rasp Pi and the open source, compact SIMPL messaging toolkit are a natural fit for application developers.

As a developer of Raspberry Pi applications, you will want your code to be modular. This is especially true as your Raspberry Pi applications become more sophisticated and complex. Encapsulation, for ease of testing algorithms and modules, is a big asset in any toolkit. The SIMPL toolkit encourages encapsulated modular design and greatly facilitates testing.

The Raspberry Pi can be programmed in any number of languages. As a developer, you may want your application to have the speed and efficiency of C with the ease of coding and extensive libraries that the popular Raspberry Pi language Python sports. @L 

The SIMPL toolkit allows modules to be written in any of the supported languages, including C, C++, Python, Java, Tcl/Tk, or PHP. These modules can be mixed in any given SIMPL application. A Raspberry Pi developer using the SIMPL toolkit has the flexibility to use Python where it fits best and C where speed is needed. If you want to connect your Raspberry Pi seamlessly to the cloud or to a deeply embedded device such as the Arduino, then the SIMPL toolkit can make that transparent and easy.

In this article, I'll introduce the SIMPL toolkit, guide you through the installation on your Raspberry Pi, and work through some illustrative examples.

SIMPL Applications

A SIMPL application consists of two or more SIMPL modules connected by a messaging channel. Each SIMPL module is a separate Linux process. The messaging channel is a block of shared memory moderated by a named FIFO. The namespace associated with these FIFOs is called the SIMPL sandbox.

The SIMPL toolkit is programming language agnostic. The SIMPL toolkit exposes several compact, shared libraries that enable the creation of modular, highly encapsulated, and network-transparent SIMPL applications. The core SIMPL library is written in C, and the code is open sourced under the LGPL license. Other SIMPL libraries are available for Python, Java, and Tcl/Tk.

SIMPL is efficient. The toolkit API is as easy as it gets. Most applications require a subset of only five functions:

  • name_attach
  • name_locate
  • Send
  • Receive
  • Reply

The SIMPL shared libraries are correspondingly tiny.

SIMPL is network transparent. These SIMPL modules can be distributed across one or more Raspberry Pis or into the cloud to form a seamless application. All of the required networking code is fully encapsulated in generic network surrogates that come with the SIMPL download. These surrogates allow the Raspberry Pi developer to focus solely on the business logic of the application and not worry about any networking details. In fact, most modules can be written and tested on a Raspberry Pi and then deployed on the network without change.

SIMPL is OS and device friendly. One of the surrogates that comes with the SIMPL download encapsulates a particular TCP/IP protocol [1] that is suitable for communicating with non-Linux operating systems or deeply embedded devices such as the Arduino. This means an Arduino algorithm can be made to appear as a local SIMPL module on the Raspberry Pi, greatly simplifying the interface between the Raspberry Pi and the Arduino algorithm.


Send/Receive/Reply messaging is not a new idea (see the "Background" box). QNX [2] has offered this capability at the core of its OS since the early 1980s. Moreover, you need not consider interprocess messages to understand what is meant by Send/Receive/Reply. In fact, every function call can be thought of as a special case of Send/Receive/Reply. When a mainline section of code encounters a function call, parameters (analog of the message) are pushed onto a section of memory called a stack, and execution is transferred to the first line of the function.


In the late 1990s, a group of QNX [2] developers, including me, got together for the purpose of recreating QNX-style Send/Receive/Reply messaging for Linux. The Synchronous Interprocess Messaging Project for Linux (SIMPL) open source project [3] was born.

The code at the core of the SIMPL toolkit was issued under the liberal LGPL[4] licence. As such, it has always been available for inclusion in the widest possible variety of projects. Being open source, all of the source code at the core of SIMPL has always been open for inspection and customization.

Since its beginnings more than 15 years ago, the SIMPL toolkit's capabilities have expanded steadily. Early SIMPL developers were restricted to creating SIMPL modules in the native language of the toolkit: C. Lots of SIMPL applications are still written in C. Over the years, shared libraries were created to expand the programming reach to include C++, Python, Java, Tcl/Tk, and PHP.

More importantly, because the only interface between two SIMPL modules is a contiguous block of bytes in shared memory, individual modules in a given SIMPL application can be written in different languages (e.g., a Python module can easily connect and communicate with a module written in C).

Early SIMPL applications were restricted to running on a single network node. A lot of effort early on in the SIMPL project was devoted to creating and perfecting the SIMPL TCP/IP network surrogates. Today, SIMPL supports two network transmission protocols: TCP/IP and RS232. A properly designed SIMPL module can be unit tested locally against communication partner stubs and then deployed on a wide area network without change.

Another way to think of this is that the function is blocked, waiting to be called. The mainline code blocks when the function call is made and waits for the response (analog to the reply message) from the function. This response in turn unblocks the mainline code, which continues executing at the next statement after the function call.

To a SIMPL module, a message is a contiguous block of bytes in shared memory. SIMPL imposes no protocol or structure on this message. However, to be useful, the developers of the sender and receiver modules must agree on the message's internal structure. In a typical SIMPL project, a significant portion of the design effort has nothing to do with SIMPL per se but is related to the design of this message structure.

Many message structuring protocols have been used in SIMPL applications, ranging from basic text strings to complicated XML formats. One of the earliest (and still one of my favorite) protocols is called binary tokenized messaging. Binary tokenized messages are very compact, efficient to encode and decode, and extremely extendable. In this article, I will be using binary tokenized messaging in all the examples.

It is important to reiterate that SIMPL does not impose binary tokenized or any other structure on the SIMPL message. The SIMPL core library only looks after routing the contiguous block of bytes to the correct destination and synchronizing the message pass.

In a SIMPL message pass, the following sequence occurs:

  1. The receiver module attaches a name to a communication channel and blocks, waiting for a message to arrive.
  2. The sender module locates and opens the communication channel to the receiver.
  3. The sender composes and encodes the message.
  4. The sender transmits the message to the receiver and blocks, waiting for a reply.
  5. The receiver unblocks and reads in the message.
  6. The receiver decodes the incoming message and executes an algorithm to generate a reply message.
  7. The receiver encodes this response and transmits the reply back to the sender.
  8. The receiver blocks for a new message.
  9. The sender unblocks and processes the response message.

Every SIMPL message pass involves these steps. Like the function call, a SIMPL message pass is synchronous and deterministic. As such, even a complex SIMPL application will always follow a predictable execution path. The synchronous messaging characteristics are exploited to create the network transport surrogates so central to the SIMPL toolkit.

Deterministic behavior is very desirable in a software application. SIMPL applications will remain deterministic regardless of how the modules are distributed on the network. Performance between a local distribution and a wide distribution will differ, but the sequence of execution will always remain predictable. This feature cannot be overemphasized as your Raspberry Pi applications grow in complexity.

Buy this article as PDF

Express-Checkout as PDF

Pages: 8

Price $2.95
(incl. VAT)

Buy Raspberry Pi Geek

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content