Simple example

[daanpape]

Hello,

I've recently discovered this repository after searching for a reliable broadcast solution without the need for a centralised broker (like MQTT).

Reliable for me means the following:

• Every node in the group which is connected to the network will receive exactly 1 and only 1 copy of the message.
• Messages are delivered to the application as a hole and not fragmented.
• Nice to have but not required: messages from the same sender node are delivered in order.

I'm not a theoretical person but I briefly traversed the paper and if I understood correctly this is exactly what the hyparview algorithm does based on the Plumtree gossip protocol.

I now want to do 2 things:

• Test this code out by creating a group of 3 nodes and let them send messages to each other.
• In case this is what we need I will port this library to C so that it can run on resource constrained devices.

Now to the point. It would be very helpful if an example program could be supplied which allows us to test the library. I'm willing to write this but I would need a head start as my Rust is a bit rusty.

Kind regards,
Daan

[sile]

Hi,

Sorry for the late reply.
A real usage example of this crate is found in https://github.com/sile/plumcast (plumcast isn't a small crate though ...).

It is possible to create a simple example, but I'm concerned that HyParView(and Plumtree) may not meet your requirements. Please see https://docs.rs/plumcast/0.1.5/plumcast/#cons.

[daanpape]

Hi Sile,

Thank you very much for your reply. I was in the assumption that HyParView was an extension on Plumtree which guaranteed that a message arrives.

I will try out the plumcast program, thank you for the link.

[sile]

I was in the assumption that HyParView was an extension on Plumtree which guaranteed that a message arrives.

In my understanding, the main role of HyParView is membership management of a cluster.
It is scalable, fault tolerant and it doesn't require a central node. However there is no strong guarantee about connectivity of a cluster. With pure HyParView algorithm alone, in very rare cases, cluster split may occur (and HyParView cannot detect the split).
To detect the split, I sometime implement heartbeat mechanizm that uses a strong consistent service (e.g., etcd, consul) for checking the connectivity of a cluster.

The main role of Plumtree is enabling an efficient message broadcast.
Plumtree uses HyParView (or something else) for underlaying cluster member management.
Plumtree builds and manages a fault-tolerant, dynamic spanning tree on the top of the underlying cluster, and broadcasts messages through the tree.
The one of the most difficult points of Plumtree is deciding on an appropriate message buffer size.
If the buffer size is too small, some messages may drop or be delivered more than once. Conversely, if the buffer size is too large, it may exhaust system memory (RAM).