From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-f68.google.com (mail-lf1-f68.google.com [209.85.167.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id F1B15469719 for ; Wed, 26 Feb 2020 13:18:20 +0300 (MSK) Received: by mail-lf1-f68.google.com with SMTP id 83so1529058lfh.9 for ; Wed, 26 Feb 2020 02:18:20 -0800 (PST) Date: Wed, 26 Feb 2020 13:18:19 +0300 From: Konstantin Osipov Message-ID: <20200226101819.GA15433@atlas> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Tarantool-patches] [PATCH v4 3/4] replication: implement an instance id filter for relay List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: sergepetrenko Cc: kirichenkoga@gmail.com, tarantool-patches@dev.tarantool.org, v.shpilevoy@tarantool.org Generally I think you're on track with these series. I believe it will also be possible to use this filter to not send records twice in a full mesh. E.g. you could add a follow up patch which excludes from the subscription peers to which we have a direct connection, this will easily solve the full-mesh replication traffic explosion issue, the replica will only get the changes directly from the peers. Please solicit a detailed review. * sergepetrenko [20/02/26 13:00]: > + unsigned int map_size = __builtin_popcount(id_mask); > + if (map_size) { > + size += mp_sizeof_array(map_size) + map_size * > + mp_sizeof_uint(VCLOCK_MAX); > + } Better:mask_size. Besides, this is perhaps not id_mask, but id_filter. The difference is that mask is something inclusive, i.e. if you're in the mask, you get the records, while filter is something exclusive, if you're not in the mask, you don't get the records. -- Konstantin Osipov, Moscow, Russia