Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1

Ted Lemon <mellon@fugue.com> Sat, 05 December 2015 05:47 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: storagesync@ietfa.amsl.com
Delivered-To: storagesync@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11D9C1A0091 for <storagesync@ietfa.amsl.com>; Fri, 4 Dec 2015 21:47:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.912
X-Spam-Level:
X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7K51o9kVqhPK for <storagesync@ietfa.amsl.com>; Fri, 4 Dec 2015 21:47:44 -0800 (PST)
Received: from fugue.com (mail-2.fugue.com [IPv6:2a01:7e01::f03c:91ff:fee4:ad68]) by ietfa.amsl.com (Postfix) with ESMTP id AC79A1A0087 for <storagesync@ietf.org>; Fri, 4 Dec 2015 21:47:43 -0800 (PST)
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14492944609720.2587213853839785"
From: Ted Lemon <mellon@fugue.com>
To: storagesync@ietf.org
In-Reply-To: <CAO_YprZOjDN46-kEJhmjbyokRjbPCU2KNK1xrzQiH3vQTm4w9w@mail.gmail.com>
References: <mailman.108.1449000023.26068.storagesync@ietf.org> <1449004445.2745758.455126129.5028FD2B@webmail.messagingengine.com> <CAO_YprZhCmUxEf=aGCYL=+CLbjUoD1ifpDFsrS7N40Npo4wr+w@mail.gmail.com> <1449050174.3667910.455617161.12EEE3C5@webmail.messagingengine.com> <1449051540970-b577e6c2-393e54ef-bbe05be4@gmail.com> <1449052128.3674794.455635937.667C3E1F@webmail.messagingengine.com> <CAPpPfeAdrCZcsYZo7=W6N14K4F2LutXN8BFTetikzKZSr8+vVA@mail.gmail.com> <259424f4.2bca.1516717ef55.Coremail.fsong@bjtu.edu.cn> <56600F0A.9000200@tuxed.net> <CAPpPfeDPHGR+vn0=ji9frF2kr+J=YR76g0e7yOndKzz97bxdHQ@mail.gmail.com> <566014EA.2010705@tuxed.net> <CAO_Yprbc9LMc3TmpkKpmN9hUzAix13nfuSRS5Z8jPf6xu8xjNg@mail.gmail.com> <56601F18.8030409@tuxed.net> <CAO_YpraF1UrV49Po9PZx6ZoSbcLm5gRPEKXAdTT3VvPPPWEAfg@mail.gmail.com> <1449153485919-e58fed74-d7eab50a-01b3670c@fugue.com> <D51EEF1B-13C8-4BBB-91C0-1B473D17759C@cern.ch> <1449170047359-e297ed6e-b9fd94e9-570ca980@fugue.com> <CAO_YpraSokj1S5-mZ17nMiN91c+PfHtMfGSjsFZ1zopQ59eUPQ@mail.gmail.com> <1449246571559-58500bfc-f92fedd1-047d217b@fugue.com> <CAO_YprZOjDN46-kEJhmjbyokRjbPCU2KNK1xrzQiH3vQTm4w9w@mail.gmail.com>
Date: Sat, 05 Dec 2015 05:47:40 +0000
Message-Id: <1449294461284-b55dffbc-67521f90-03218253@fugue.com>
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/storagesync/qsVl3xB2nBbzXsvznSmG1EI5paw>
Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1
X-BeenThere: storagesync@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services <storagesync.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/storagesync>, <mailto:storagesync-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/storagesync/>
List-Post: <mailto:storagesync@ietf.org>
List-Help: <mailto:storagesync-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/storagesync>, <mailto:storagesync-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 05 Dec 2015 05:47:46 -0000

Saturday, Dec 5, 2015 12:28 AM Linhui Sun wrote:
> I'm not very familiar with the distributed peer model (I view it as p2p,
> please correct me if I am wrong). From the example you have provided
> previously, it seems that it works fine with 2 participants. But I don't
> know whether it works well when multiple participants are willing to share
> a file/folder. I'm asking this question since we need to know which model
> should the iss probably employ.

The distributed peer model simply means that there is no server.   There are only instances of the database.   Any instance can be modified, and the changes will be propagated to other instances when they sync.   A change made on one instance may propagate to another instance through a third instance.

Importantly, this avoids the situation where the metadata is lost on the server, and as a consequence the data is all removed from the client.   Since there is no server, and no client, but only peers, neither peer is considered authoritative, so a metadata loss on either peer can result in a safe recovery without data loss.

In practice, in most cases there will be one or more instances that are treated as servers, and then one or more that are treated more as clients, but now you can have two or three "servers" and it doesn't matter which one the "client" syncs to; the new information will propagate to the other two "servers."


--
Sent from Whiteout Mail - https://whiteout.io

My PGP key: https://keys.whiteout.io/mellon@fugue.com