Is your feature request related to a problem? Please describe.
Right now, the peer knows only how many peers are alive and dead. But, there is no way to get details of the peer. So, we should support a way to send a message to the peer.

My use-case:
My peer listening on two ports. One is by the epidemic and another one is grpc server. All my application logic is on the grpc server. So, I need a way to communicate with my peers to get the information that I want.

How this feature helps me?

As soon I get an alive event, I'll ask for the required details which I want. Then the receiver peer will respond to my question.

Describe the solution you'd like
I need cluster.send_payload method which takes destination peer id and payload as a parameter and sends the payload to the destination peer.

• Writing to local structures
• Reading/writing from/to data protocols
• Conflict resolution and CRDT traits. (Can use other crate if exposes)

Everything compiles but that doesn't mean that sporadic failures won't occur. Failpoints should run with the run-pass test harness.

Quickwit is relying on artillery-core. A painful bug on the SWIM algorithm was recently merged, but the crates has not been published since then..

Would it be possible to have the artillery core crate published?

Currently, artillery-core detect time out responses by comparing two times based on SystemTime, see code

But using SystemTime to detect time out could lead to weird behavior as it is not monotonic. Would be nice to use Instant instead.

@Kerollmops mentioned that it is better. So let it be.

Include chaotic fail points with various randomizations to test out the current cluster configurations.

After discovering this project, I then found the CRAQ paper and began reading it. In that paper, I noticed this paragraph:

Building a fault-tolerant coordination service for distributed applications is notoriously error prone. An 
earlier version of CRAQ contained a very simple, centrally controlled coordination service that maintained 
membership management. We subsequently opted to leverage ZooKeeper however, to provide CRAQ 
with a robust, distributed, high-performance method for tracking group membership and an easy way to 
store chain metadata. Through the use of Zookeper, CRAQ nodes are guaranteed to receive a 
notification when nodes are added to or removed from a group. Similarly, a node can be notified when 
metadata in which it has expressed interest changes.

I've noticed in other implementations of CRAQ, I've seen them replace ZooKeeper with protocols like RAFT. Effectively using Raft for the coordination service and CRAQ for k/v storage.

How does Artillery maintain chain metadata for the cluster? Or is it only using epidemic protocals to distribute metadata?

Self-explanatory; We want to run checks.sh against the codebase as part of GitHub Actions.

Need to write a vector clock impl over the state passes to resolve conflicts.

• Version: artillery-core = "0.1.2-alpha.3"
• Platform: Linux tpx1cg9 5.4.72-microsoft-standard-WSL2 #1 SMP Wed Oct 28 23:40:43 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
• Subsystem:

I am building an application using artillery-core by referring to the sample here.

https://github.com/bastion-rs/artillery/blob/master/artillery-core/examples/cball_infection.rs

I have successfully brought up a three-node cluster, but when I start the third node, I get frequent SuspectedDown.
Even with a two-node cluster, there is no problem in the beginning, but after a few minutes, the SuspectedDown may occur.
What can I do to solve this problem?

We need some internal management for message types.

Lifecycle Commands (exposed)

• Stop (stops polling exec or stops the children group's elements or supervised elements)
• Kill (stops polling exec or cancels the children group's elements or supervised elements)
• Start (start polling exec or start the children group's elements or supervised elements)

Notifications

• Dead (when exec successfully finished its executiong or Stop/Kill was received or one the elements of the children group stopped)
• Faulted (when exec panics or returns an error or one elements of the children group faulted)

Direct Communication (exposed)

• Tell (a message)
• Ask (a message with a channel to answer with another message)

Remote Communication (exposed)

• Deploy (makes a supervisor supervise a new children group or supervisor)
• Prune (TODO)
• SuperviseWith (changes the supervision strategy of a supervisor)

Using docsify I have initialized the documentation under the docs. But it is not visible under bastion.rs.
Most probably artillery.bastion.rs would be the best domain to land to the documentation.

Currently, it is not visible. Let's make it visible :)