[tarantool-patches] Re: [PATCH 1/1] swim: introduce SWIM's anti-entropy component

[Vladislav Shpilevoy <v.shpilevoy@tarantool.org>]

Sorry again - ignore the whole email. I've found a bug
which required drastic changes in the event loop
implementation.

I've sent a new version as v2.

On 06/03/2019 18:13, Vladislav Shpilevoy wrote:
> SWIM - Scalable Weakly-consistent Infection-style Process Group
> Membership Protocol. It consists of 2 components: events
> dissemination and failure detection, and stores in memory a
> table of known remote hosts - members. Also some SWIM
> implementations have an additional component: anti-entropy -
> periodical broadcast of a random subset of members table.
> 
> Dissemination component spreads over the cluster changes occurred
> with members. Failure detection constantly searches for failed
> dead members. Anti-entropy just sends all known information at
> once about a member so as to synchronize it among all other
> members in case some events were not disseminated (UDP problems).
> 
> Anti-entropy is the most vital component, since it can work
> without dissemination and failure detection. But they can not
> work properly with out the former. Consider the example: two SWIM
> nodes, both are alive. Nothing happens, so the events list is
> empty, only pings are being sent periodically. Then a third
> node appears. It knows about one of existing nodes. How should
> it learn about another one? Sure, its known counterpart can try
> to notify another one, but it is UDP, so this event can get lost.
> Anti-entropy is an extra simple component, it just piggybacks
> random part of members table with each regular round message.
> In the example above the new node will learn about the third
> one via anti-entropy messages of the second one soon or late.
> 
> This is why anti-entropy is the first implemented component.
> 
> Part of #3234
> ---
> Branch: https://github.com/tarantool/tarantool/tree/gerold103/gh-3234-swim-anti-entropy
>