Introduction
Mles (Modern Lightweight channEl Service) is a professional-grade distributed publish-subscribe data service built on Rust, Tokio, and Serde. This lightweight yet robust solution provides authenticated messaging channels that operate seamlessly across IPv4 and IPv6 networks over TCP, ensuring reliable data transfer on all Rust-supported platforms including Linux, macOS, and Windows.
Why Choose Mles?
Mles delivers a streamlined publish-subscribe architecture for applications requiring reliable channel-based message exchange. The connection model is designed for simplicity and efficiency: clients connect directly to their desired channel and immediately begin exchanging messages without additional setup procedures. When finished, clients simply close their connection.
Key advantages include:
- Scalability through advanced connection handling built on Tokio futures
- Format-agnostic message passing that preserves client data structure integrity
- Modern, high-performance authentication mechanisms effective even with minimal inputs
- Lightweight Rust-based architecture delivering superior performance compared to alternatives
Technical Overview
The Mles protocol leverages TLS WebSocket session packet forwarding within channels, using client identification and channel fields for routing. The reference server implementation is developed in safe Rust code that eliminates blocking operations while supporting robust session authentication between Mles clients and servers.
The dual-layer authentication architecture provides:
- Level 1: Server-client authentication
- Level 2: Client-client authentication
This approach enables clients to authenticate each other independently from servers and implement custom protocols over the Mles foundation. Clients maintain complete freedom to select their preferred data structures for message exchange.
Protocol Specification
The Mles first frame employs a JSON-based data structure consisting of a (uid, channel, auth) value triplet. The uid and channel fields are UTF-8 strings, while the optional auth field facilitates additional client-server authentication beyond TLS when required.
This represents the only mandatory message type clients need to implement. The protocol intentionally omits internal message types like "join" or "leave" notifications and avoids flags by design, resulting in streamlined message processing. Following first frame authentication, the Mles server efficiently forwards subsequent frames to all channel subscribers.
First frame JSON protocol header:
{
"uid":"<user identification>",
"channel":"<selected channel>",
"auth":"<optional authentication hash>"
}
The Mles protocol and reference implementation have reached stability with the v2.0 release. For implementation details, visit github.com/jq-rs/mles-rs and the mles.io/blog. Stay updated with the latest news on the /c/mles channel.
Advanced Features
Server Connectivity with Proxy-Clients
In Mles v2, there has been a architectural change in how servers connect. Instead of the previous model where servers connected directly as peers and shared all channels, the new approach implements a proxy-client model that enables channel-specific connections between servers.
The proxy-client functions as a standard client from the perspective of both servers, but its role is to bridge a specific channel between them. Multiple proxy-clients can connect different channel combinations across various servers, creating a highly customizable distribution network.
Message History
Mles servers and their connected channels can provide message history functionality to deliver previous messages to new client connections. Unlike conventional approaches, Mles does not maintain a queue that tracks message delivery status. Instead, it efficiently resends available history to reconnecting clients, including proxy-clients.
This streamlined approach guarantees that clients receive all channel history following a connection interruption. Clients can determine if new messages were posted during disconnection periods and identify whether their own messages require retransmission. While these capabilities are available, they remain optional for clients that don't require such functionality.
In distributed environments, proxy-clients also facilitate resynchronization of channel history during scenarios such as server restarts, providing resilience without requiring client intervention.
Implementation Scenarios
Reliable, authenticated, and scalable data distribution is essential for many modern applications. Mles provides an ideal foundation for such services.
Simple Channel Configuration
In the basic implementation, multiple clients connect directly to a public server on their designated channel. Each client communicates with others on the same channel through the server.
Distributed Channel Configuration
For more complex deployments, channels can be selectively distributed across multiple servers using proxy-clients. Clients may connect to any server in the network while maintaining access to shared channels.
Any hierarchical arrangement of Mles servers with proxy-client connections provides efficient message distribution across the network.
Potential Applications
Services that would benefit from Mles architecture include:
- Configuration distribution systems
- IoT telemetry platforms
- Any publish-subscribe service without database requirements
Mles is particularly well-suited for applications with numerous clients distributed across a limited number of channels. Since the channel joining mechanism operates per connection and channels cannot be multiplexed on a single connection, Mles may not be optimal for clients requiring access to a very large number of channels simultaneously.
Client Protocol Design Considerations
Developing a lightweight Mles client is straightforward, requiring only knowledge of the data structure to be exchanged with other clients. However, when implementing history functionality, clients should anticipate potential message duplication during error recovery scenarios.
Recommended design practices include:
- Implementing per-user sequence numbers to identify and filter duplicate messages
- Developing resynchronization capabilities for reconnecting to the message history
- Creating mechanisms to retransmit lost messages when high reliability is required
For channel membership awareness, clients can monitor initial frames sent during connection attempts. These frames provide user and channel information that allows clients to track active subscribers. For departure notification, either a custom messaging protocol or keepalive mechanism can be implemented at the client layer.
The open-source mles-client and MlesTalk applications provide reference implementations demonstrating these concepts.
Future Development
The reference implementation roadmap includes performance optimizations and resilience enhancements. Additional extensions may be considered provided they maintain alignment with the core principles of Mles.
To preserve the lightweight, compatible, and understandable nature of the service, the Mles protocol itself is stabilized as of the 2.0 release, with no further changes permitted. Standardization may be pursued to formalize this commitment.
Client-side innovation remains unrestricted, with new service types and protocol implementations welcome as second-level additions. We encourage sharing client implementations as examples for the community. Please inform us of your developments in this area.