Home

Mles Overview

Mles (Modern Lightweight channEl Service) is a lightweight, robust and fast authenticated distributed publish/subscribe data service based on Rust (a safe, concurrent and fast systems language), Tokio (asynchronous I/O for Rust) and Serde (Serialization framework for Rust). It works seamlessly with IPv4 or IPv6 on TCP, which provides its reliable data transfer backbone.

Mles is based on Mles protocol (IANA port# 8077) which has a lightweight header structure with SipHash based authentication. The reference server implementation is lock-free (no blocking!) and supports strong session authentication between Mles client and server. With its two layer authentication scheme (1st level: server-client, 2nd level: client-client) it provides possibility for clients to authenticate each others independently from servers and also to build any additional protocol over Mles they may need.

Mles data structure is based on CBOR (Concise Binary Object Representation). It consists of (uid, channel, message) value triplet where uid and channel are UTF-8 Strings and message can be of any type of payload.

Mles servers can be connected together by defining peer servers. This provides a simple but yet powerful way to distribute data between servers.

Mles example client provides also simple WebSocket proxy implementation which allows to use Mles without opening additional public ports, if that is not in some cases feasible.

For more information about Mles reference implementation, see https://github.com/jq-rs/mles-rs.

Use cases

Often it is important that any data can be distributed in a scalable and properly authenticated but still reliable way. These services can take advantage using Mles as a backbone service. In a common case a client is connected directly to a public server. In another common case there are two servers, one public server and one internal server and clients connect to the internal server.

Services that would have most benefit of the Mles could be e.g. IoT telemetry and configuration distribution. For a giant large scale services, such data distribution combined with a proper TCP offload engine (TOE) could provide a very scalable distributed service or telemetry collection between any number of devices and servers.

Future development

In the future reference implementation may be enhanced with new services, e.g. means to do hitless server upgrade with peer server backup support or assisting client. Even more scalable multi-core versions could be provided as a separate release although current implementation should scale very well on most use cases with proper distribution.

Changes to protocol itself are not allowed after 1.0 release as a simple protocol means lightweight, compatible and understandable service.

On client side of course any new type of service can be introduced as a 2nd level service.