jq-rs / mles-rs Goto Github PK

In case there are a lot of connections on the channel, the random cid may cause client connections to fail. The cid should be deterministic with dependency to uid.

Since 0.5.3

Add peering support to Mles v2 similar to Mles v1:

• Peer address config via CLI
• Send history to connecting clients when peer not connected/down

The following error is noticed when second client connects to server with a peer server "Error: Incorrect message length"

At the moment, Mles server does not prevent loops and user needs to define carefully tree-like structure for the Mles network. Add a loop prevention mechanism to Mles server which will create tree-like structure autonomously.

shared key with address is not supported

After cid loop fix, resync support does not work properly during server restart. There needs to be some logic when thread is canceled vs. reconnect is tried.

Move command line handling from custom to use clap.

WebSocket connection is currently supported in Mles client only, add it to Mles reference server too.

Add support for multiplexing over WebSocket proxy as specified. This would allow WebSocket client to have subscriptions to several channels over same WebSocket connection. It is already supported by the Mles protocol specification.

Add support for Tokio without core dependency.

Could be a library problem, will check.

peer handling is not supported by 0.5-release

Update to Tokio 1.0

In case there a Mles network tree and root restarts, this cannot be seen by client who trusts history notifications to state resync in case of data loss.

Looks very nice. I like the minimalist and clear interface.

It will take some work to evaluate so easing that may help with adoption.

My questions after first look are the security model or how you would integrate one (authentication, keys ..) and redundant top level server setup to avoid a single point of failure without the looping issue which you mention there are guards for.

Closed/Errorneous connections should be removed from channel. At the moment they are left there, causing eventually unnecessary load in send processing.

Protocol input fuzzing would be nice! Maybe with cargo fuzz tests.

An unused channel should be completely removed after a configurable time period e.g. one week.

Add load-balancing/protection support with configurable peer-CID. Update specs accordingly first.

Windows enter is not handled properly and causes weird looking lines when it is used as client.

Take Bytes crate into use in the packet processing. Minimize copying with reserve(), split_off(), extend() + clone() pattern.

Add support for async/await when released on stable.

Add support for Rust 2018 edition

Some cases a message may be lost.

Limit CID connection drop per channel. This would allow to use the same CID on different channels and increased scalability.

Add optional TLS support for session to the reference implementations.

Add authentication support for Mles v2 with optional JSON auth field. Use MLES_KEY environment variable similar to Mles v1.

I'm currently using MQTT client (implemented in Rust) to push data through to server. We're using cloud solutions as MQTT server which works fine, however I'm looking for a light weight option for use cases where cloud providers cannot be used. I could use RabbitMQ with MQTT adapter but I was wondering if it's possible to use this library with adapter for MQTT. I really like the simplistic approach this library has taken - thanks for open sourcing it.

In case the first connection for a peer has invalid/duplicate cid, the peer connection stays in a loop forever as it cannot update peer cid anymore.

0.5.3