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

Ted Lemon <mellon@fugue.com> Mon, 07 December 2015 04:02 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 18BC31B2C31 for <storagesync@ietfa.amsl.com>; Sun, 6 Dec 2015 20:02:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.612
X-Spam-Level:
X-Spam-Status: No, score=-1.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 XaPPteFrzI-Y for <storagesync@ietfa.amsl.com>; Sun, 6 Dec 2015 20:02:29 -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 B93531B2BCA for <storagesync@ietf.org>; Sun, 6 Dec 2015 20:02:25 -0800 (PST)
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14494609406210.39082355983555317"
From: Ted Lemon <mellon@fugue.com>
To: fsong@bjtu.edu.cn
In-Reply-To: <2015120711591198474787@bjtu.edu.cn>
References: <20151204181110.GA2418@localhost.localdomain> <1449255654746-36498631-5591108f-793d865a@fugue.com> <8F085EBA-F6A4-4FBD-8B8E-1F9AE114FD05@unterwaditzer.net> <CAO_YpraJsDKbOXD9MdxHqeAYTMoiZFyViHX+P2PtD=9hpRz9MQ@mail.gmail.com> <20151206173646.GA6290@localhost.localdomain> <1449447450498-61af5a96-1c461047-3019ac1e@gmail.com> <20151207002020.GA5002@localhost.localdomain> <1449448362292-7d42d496-109559e8-4177b3f9@gmail.com> <20151207003810.GA24130@localhost.localdomain> <1449449404474-72724227-c54ecf87-7d18f3b0@gmail.com> <20151207005426.GA29483@localhost.localdomain> <CAO_YpramyzAZ8hS6aphmBNw2FiKTpesb9uW7uGHtjRH_YkPAJg@mail.gmail.com> <1449452139832-4f314827-a7ecd596-c5312339@fugue.com> <1449454580239-1fd59d90-52f0231b-370f2ef5@gmail.com,> <> <1449455245871-cb7e86e1-1a0160c5-aa6acce3@fugue.com> <2015120711170621874681@bjtu.edu.cn,> <1449459616112-6043cb32-cd69a1f9-1399f1c0@fugue.com> <2015120711591198474787@bjtu.edu.cn>
Date: Mon, 07 Dec 2015 04:02:20 +0000
Message-Id: <1449460940935-350ed1d5-a3d32a34-254205b2@fugue.com>
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/storagesync/L_IVXpNRBTmDPMQxNutWlL6_dcs>
Cc: storagesync@ietf.org
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: Mon, 07 Dec 2015 04:02:30 -0000

Sunday, Dec 6, 2015 10:59 PM Fei Song wrote:
>>0: File F is at version 0
>>1: Client A syncs to server
>>2: Client B syncs to server
>>3: File f changed on Client A -> Version 0.A
>>4: File f changed on Client B -> Version 0.B
>>5: Client B syncs to server, updating file F to version 0.B, modified time = 4
>>6: Client A syncs to server: what happens?
>>   a: File updated to version 0.A, modified time=3
>>   b: Server overwrites version 0.A with version 0.B, changes in 0.A lost
>>   c: Conflict resolution combines versions 0.A and 0.B, producing version 1, mod time=6

>>I think C is the only right answer.   We want conflict resolution to be automatic whenever possible, but we do want to do conflict resolution, and not just wipe out changes, because those changes may contain real work that the user on client A did.
> 
> These "middle" changes are important. Yeah. they should be stroed at the server side.
> Wiping out changes is just a simple appoach.
> I also think c is a good option. Then we need to consider a suitable time window.
> e.g. how long should be consider as a "simultaneous" updating.
> otherwise F might be updated as Version 1 directly.

In option C, the time doesn't matter at all.   It's the fact that the two versions are different that triggers the conflict resolution process.   So there's no timing race to worry about: the first client to update just succeeds, and the second client to update has to do conflict resolution.   Doesn't matter which client updates first, or when the updates happen.


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

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