Questions and issues around integration into an asynchronous environment

[drewstone]

Issue

One of the main issues we are having in our environment seems to stem from the fact that peers in our network start the protocol at different times. Since they start at different times, they send the initial messages at different times. It just so happens that we think messages are received by other peers before they have initialized the relevant structs for handling those messages and, as such, those messages go unprocessed. We are considering adding a queue-based cache for each participant, but we are curious if there are more ideas/recommendations @DmytroTym @survived?

Questions

1. Does the system process out-of-order messages at all or does it expect protocol to work sequentially.
2. Does the library provide replication over messages that have that been ACK'd effectively? For example, a peer has sent a message and has not been able to proceed in the round so it can send that same message again?

[Iraklis Leontiadis]

Great comments @drewstone. The crate does not provide networking stack it is only the cryptographic codebase. So it is up to the user to implement it. Sees those comments are more relevant for the rounds-based-protocol or the Gotham city. In general assuming there is a message to be signed it will simplify a lot verifying at the beginning that there are those n peers live and active that will collaborate to sign the message. There should be some coordination that all those peers are up and running. I guess those two questions are more relevant with those lacking issues ZenGo-X/round-based-protocol#3