Discussion: racing for replies

[bchamagne]

Is your feature request related to a problem?

Actually if a node do a quorum_read to get some data, it will ask 3 near nodes and will wait for the 3 replies to continue the work. If one of these "near nodes" is really slow, this quorum will wait until timeout.

Could we ask for more nodes and then only take the fastest 3 for example?

Describe the solution you'd like

We could change the consistency_level flag to be a pair {nbRespToContinue, nbMsgToSend}

Additional context

What do you think?

[bchamagne]

We could even "cancel" the not-needed-anymore messages by sending them a cancel request that kills the pid handling the msg (we would need a message_ref). Very similar to javascript fetch

[samuelmanzanera]

I thought about this idea few times ago. I was wondering if it wasn't overkill to send a message to cancel a message. Because probably during the time to get the cancel message, the prior message would have been executed.

I think the latency is more on the P2P communication instead of message's processing. But we might have congestion or pressure some times due to the load.

[samuelmanzanera]

It's the reason of the network patch. To be able to flag the responsiveness of a node, by its real/aggregated latency

[samuelmanzanera]

Nice idea 👍