After some proof-of-concept, peering does indeed work fine with the additional peer-field. However, it does not allow a way to multiplex messages over a peer connection. I think we want that for peering.
To do that, a better approach is probably to introduce a new peer-specific message for the handshake, e.g. { “peer-id”: x, “auth”:“optional hash” }. To leverage the same connection for several uids, the peer connection will always encapsulate the channel header with the message to be able to identify different uids. This is some overhead, but still better than having connection per channel between peers. This is quite similar to Mles v1.
For simplicity, bundling messages over peer connection will not be supported at this point.
As always, comments are welcome!
You must log in or # to comment.
In the end, I felt uneasy to allow servers to connect wherever without clients knowledge. Instead of server supporting peering, we can choose proxy-client type of approach where the client decides which channel they want to replicate between two servers. It works amazingly well and also removes the centralized wibes of hierarchical forwarding - now everything is truly distributed with clients in control. Please check https://github.com/jq-rs/mles-client for a reference implementation example. Enjoy!