this post was submitted on 12 Feb 2024
3 points (100.0% liked)

Modern Lightweight channEl Service

30 readers
2 users here now

All things related to Mles, Mles WebSocket, and their clients. See https://mles.io for more info about Mles (Modern Lightweight channEl Service) -protocol.

founded 1 year ago
MODERATORS
3
submitted 9 months ago* (last edited 9 months ago) by marsuplane to c/mles
 

As Mles is a hierarchical protocol that allows the definition of at least one peer, peering is a very relevant feature. With Mles v2 the peer node concept was postponed to be defined in detail later. And here we are!

The peering concept itself is similar to Mles v1, an Mles node can define a peer that points to a higher hierarchy node in the Mles network. In v2 the peers will do a simple handshake. This ensures that peer connections are identified and optionally authenticated both ways. Also, loop avoidance is built into the protocol naturally. When a node connects to a peer, it will send roughly the following message

{
	"uid":"randomly generated for the node",
	"channel":"example",
	"auth":"hash",
        "peer": true
}

The receiver will reply to the message its uid message which completes the handshake. The initial peer message or its reply will not be forwarded to other clients. However, they are forwarded to other peers. After this, the client messages will be multiplexed over this peer connection.

If there is a valid peer connection in a node, the node does not forward message history to clients, the higher hierarchy peer will do it when a new client joins a channel. This is similar to Mles v1. The peer uid will be saved to uid-table and prevent accidental loops in the peering. Thus, it is safe to connect nodes bidirectionally together or into a ring: the network will automatically organize into a loop-free hierarchy.

So, this is the future peering concept in general (to-be-implemented). Nevertheless, to further improve the peering availability and make it more difficult to monitor which channel members communicate in the network by following packets-only, it would be preferable to be able to define several peers, even by a file or via http get from a location. With several peers defined, there are choices to be made on how to organize the peering when network issues occur. Comments are welcome on how to do it best!

And of course, comments in general to peering, especially if you catch an issue in the design, are very welcome as well.

no comments (yet)
sorted by: hot top controversial new old
there doesn't seem to be anything here