Exchanging messages between applications in a network is a simple task as long as you just send a single message at a time, wait for a reply and send the next message.

About libTML

Synchronous communication can be achieved by many existing protocols if the intended communication pattern is client/server. Establishing an asynchronous, multithreaded, bidirectional communication without blocking messages can be time consuming and error prone. Using libTML allows to implement asynchronous message exchange on top of the IETF standard protocol BEEP (Blocks Extensible Exchange Protocol) without the need of fiddling around with the basics of message processing. All work can be put into the features of the application instead of taming a TCP/IP socket.

Why BEEP ?

Much too often network message exchange is reinvented, but the basic mechanisms remains similar. The Internet Engineering Task Force (IETF) released a standard for a universal messaging protocol in 2001. The Blocks Extensible Exchange Protocol (BEEP) combines best practices of protocol design into a single standard (RFC 3080/RFC 3081) and introduces profiles to make the actual content of messages and communication patterns customizable. The goal of this approach is to allow the reuse of the basic mechanisms of message exchange. The TML Messaging Suite is based on BEEP because of its powerful features like channels, flow control and multiplexing.

Why Flow Control and Multiplexing ?

A TCP connection is a full duplex stream of data. Multiplexing is required to achieve asynchronous messaging on a stream, which makes sure the data is received in the same order as sent previously. Larger messages are split into smaller pieces on the wire. These packets are received in a buffer to be reassembled. Flow control prevents an overflow of the receiving buffers. Flow control and multiplexing are well known from TCP itself. This raises the question why it is required in an application protocol like BEEP. The answer is performance! Protocols without the ability of asynchronous communication, work around this limitation by using multiple TCP connections. If a lot of small messages have to be exchanged, the time to negotiate a TCP session and to get over the starting phase of the data transfer reduces the usable bandwidth and increases response times significantly.

Why not only BEEP, why libTML ?

A protocol for an asynchronous transfer of messages is a good starting point, but to use it efficiently some more things are required:

  • Message syntax and semantic.
  • Data encoding.
  • Communication patterns.

The TML Messaging Suite includes an API to create and read hierarchical data structures. This Simple Data Exchange (SIDEX) API provides a variant data type implementation with reference counting, to simplify the usage of lists or dictionaries and all other basic data types. The APIs are available on multiple platforms and for a variety of programming languages, even if there is no native support of a certain data type in a language.

Some prepared communication patterns, like publish/subscribe or events, can be used out of the box. The BEEP single call multiple answer pattern is applied for timeout control, load balancing and a command dispatcher to simplify the creation of interfaces.

Most of your recurring problems in inter process communication can be solved by making use of libTML’s features.

Why libTML for the Internet of Things

One of the challenges in the future of the Internet of Things is to connect to mobile and legacy internet applications. Because of the special requirements like constrained devices many different protocols where published, designed for lightweight implementations, sensors and weak, low bandwidth connections. BEEP and libTML allow to mimic the design patterns of TCP IoT protocols. But more important, libTML can scale from a single connection publish/subscribe protocol to a single connection asynchronous messaging protocol to control complex Cyber Physical Systems with many sensors/actors and peers. With an evolving Internet of Things, this will become a valuable asset.

Why only TCP ? - The future of libTML

Currently libTML is using TCP as its data transport layer, but BEEP itself is defined independently from any specific transport protocol. This opens the opportunity to use libTML across different network technologies. Devices can be connected through near field, wire less data transfer like Bluetooth or even a simple serial interface, without modifying the application. WebSocket transport will make no difference as well. Supporting a variety of transport protocols is on the road map for version 2 of libTML.

Try it!

Try libTML to figure out if it is helpful for your project. You can download the sources on GitHub. You can find additional information on the TML documentation page. If you have questions or want to get involved subscribe to the TML mailinglist. For professional support, send an email to support@libtml.org.