From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id D2FDA2491A for ; Wed, 6 Mar 2019 16:24:13 -0500 (EST) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nGTj9s3rhkYW for ; Wed, 6 Mar 2019 16:24:13 -0500 (EST) Received: from smtpng3.m.smailru.net (smtpng3.m.smailru.net [94.100.177.149]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTPS id 7909E246A8 for ; Wed, 6 Mar 2019 16:24:13 -0500 (EST) Subject: [tarantool-patches] Re: [PATCH 1/1] swim: introduce SWIM's anti-entropy component From: Vladislav Shpilevoy References: <5deb15eab37345ba1abc8772a4c78308d8e8f9c1.1551884926.git.v.shpilevoy@tarantool.org> Message-ID: Date: Thu, 7 Mar 2019 00:24:11 +0300 MIME-Version: 1.0 In-Reply-To: <5deb15eab37345ba1abc8772a4c78308d8e8f9c1.1551884926.git.v.shpilevoy@tarantool.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: tarantool-patches-bounce@freelists.org Errors-to: tarantool-patches-bounce@freelists.org Reply-To: tarantool-patches@freelists.org List-Help: List-Unsubscribe: List-software: Ecartis version 1.0.0 List-Id: tarantool-patches List-Subscribe: List-Owner: List-post: List-Archive: To: tarantool-patches@freelists.org Cc: kostja@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 >