[Storagesync] recent issues discussed

"Fei Song" <fsong@bjtu.edu.cn> Wed, 02 December 2015 02:59 UTC

Return-Path: <fsong@bjtu.edu.cn>
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 2AD011B31B6 for <storagesync@ietfa.amsl.com>; Tue, 1 Dec 2015 18:59:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.688
X-Spam-Level: **
X-Spam-Status: No, score=2.688 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, MIME_BASE64_BLANKS=0.001, RCVD_IN_PSBL=2.7, 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 j_TD1oszOPFV for <storagesync@ietfa.amsl.com>; Tue, 1 Dec 2015 18:59:00 -0800 (PST)
Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with ESMTP id 142B71B31B5 for <storagesync@ietf.org>; Tue, 1 Dec 2015 18:58:59 -0800 (PST)
Received: from PC-201001061KKK (unknown [211.71.74.217]) by Jdweb1 (Coremail) with SMTP id Mp5wygBHqBEFX15WjicDAA--.8804S2; Wed, 02 Dec 2015 11:01:25 +0800 (CST)
Date: Wed, 02 Dec 2015 10:58:56 +0800
From: Fei Song <fsong@bjtu.edu.cn>
To: storagesync <storagesync@ietf.org>
References: <CAO_YprZTz+O-e82hsTgMBOLr645jJqbhtVKngubnLhimyfB2cg@mail.gmail.com> <71E522FC-C622-4DDE-B444-5CE902980823@cern.ch> <2015112611280303192311@bjtu.edu.cn>, <CAO_YprbsHsDYewHh38uDJ6gOoSZKwO8MoCR+UHz21iarEqEQOA@mail.gmail.com>
X-Priority: 3
X-Has-Attach: no
X-Mailer: Foxmail 7.0.1.91[cn]
Mime-Version: 1.0
Message-ID: <201512021058557812287@bjtu.edu.cn>
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
X-CM-TRANSID: Mp5wygBHqBEFX15WjicDAA--.8804S2
X-Coremail-Antispam: 1UD129KBjvJXoWxKr4fGrWfuF18uw17trW7CFg_yoW7ur1UpF ZxK3WkKFWkJrWxCwn2qry29r10vrykJrW7Xrn8Jr4xJrZ0gFy3tF1Iyr4ruFyUGrWfGr1j qF1Y9ay3A3Z8AFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvjb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Cr1j 6rxdM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I8E87Iv6xkF7I0E14v26rxl6s 0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6xII jxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr 1lF7xvr2IYc2Ij64vIr41lFcxC0VAYjxAxZF0Ew4CEw7xC0wACY4xI67k04243AVC20s07 MxkIecxEwVAFwVW8GwCF04k20xvY0x0EwIxGrwC20s026c02F40E14v26r1j6r18MI8I3I 0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jr0_JrylIxkGc2Ij64vIr41lIxAI cVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcV CF04k26cxKx2IYs7xG6rWUJVWrZr1UMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2 jsIEc7CjxVAFwI0_Jr0_Gr1l6VACY4xI67k04243AbIYCTnIWIevJa73UjIFyTuYvjxUyK hFDUUUU
X-CM-SenderInfo: aytwlqpemw3hxhgxhubq/
Archived-At: <http://mailarchive.ietf.org/arch/msg/storagesync/DrsrRmMuCuGK7rPwcz-RuaYIlLU>
Subject: [Storagesync] recent issues discussed
X-BeenThere: storagesync@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: fsong <fsong@bjtu.edu.cn>
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: Wed, 02 Dec 2015 02:59:02 -0000

I add this into "recent issues discussed". Here is the latest version:
 
1. The design targets of WebDAV, rsync and other existing approaches?
2. The potential use cases of ISS, such as client/server, git-like pattern, svn, etc.
3. The efficiency improvements might be the second goal for standardizing ISS protocol
4. CORS headers on storage sync APIs
5. What is needed for the ISS: a sync protocol or a generalized API
6. Some related organizations, events, projects, etc.: GEANT community, OpenCloudMesh, ownCloud, CS3, remoteStorage, ClawIO



--------------
Fei Song
>2015-11-26 11:28 GMT+08:00 Fei Song <fsong@bjtu.edu.cn>:
>
>> BTW, Based on the last sentence of last email:"The intention of this
>> message is to investigate the current state of using WebDAV for sync
>> purposes to see what needs to be improved here and whether we need new
>> protocols"
>>
>> The outcome he/she wanted might be just the links like
>> http://cs3.ethz.ch/program.html :)
>>
>In another word, I think what I want finally might be a discussion about
>"What is needed for the ISS: a sync protocol or a generalized API". Sorry
>for the poor expression : )
>
>Regards,
>Linhui
>
>>
>>
>> --------------
>> Fei Song
>> >Hello,
>> >
>> >What kind of outcome are you looking for with this analysis? Some
>> research in this area has already been done or is being done as we speak
>> >
>> >e.g. "A study of delta-sync and other optimisation in HTTP/Webdav
>> synchonisation protocols"
>> >
>> >see "Technology and Research":
>> >
>> >http://cs3.ethz.ch/program.html
>> >
>> >It would be interesting to see if there is a potential for collaboration.
>> Or maybe we already have some information you are looking for.
>> >
>> >Best regards,
>> >
>> >Jakub Moscicki
>> >
>> >―
>> >
>> >
>> >On 25 Nov 2015, at 11:45, Linhui Sun <lh.sunlinh@gmail.com<mailto:
>> lh.sunlinh@gmail.com>> wrote:
>> >
>> >Hi all,
>> >
>> >As I mentioned before, I think the developers could benefit from the IETF
>> standards. The ownCloud (https://owncloud.org/) is just an example. It is
>> developed for those who do not trust commercial storage services and want
>> to build their own network-based storage services. The ownCloud is using
>> WebDAV (RFC4918) to achieve the data sync. IMO, the WebDAV is designed for
>> distributed work but not for the sync. Thus, I made some preliminary
>> investigations on how the ownCloud uses WebDAV for sync purposes. A brief
>> summary of what I've found is in the following, please correct me if I am
>> wrong.
>> >
>> >I installed the ownCloud server (v8.2.1) on the CentOS7, and the client
>> is a desktop client on Windows.
>> >
>> >1. To find whether there is a change to the synced directory, the client
>> continuously sends PROPFIND to the server at regular intervals (around 34
>> seconds under my observation). The server will respond a 207 Multi-Status
>> Response to tell whether the main directory has been changed. To perform
>> this regular check, the client will open a new TCP connection to send the
>> PROPFIND, the server will close the existing TCP connection after
>> responding the 207 Multi-Status Response. For the next check, the client
>> will open another new TCP connection.
>> >
>> >2. Every time adding (or creating) a new file to the local folder, the
>> client will open a new TCP connection (if there is no connection existing)
>> to send the file asap. The client will first send several PROPFINDs to find
>> out which sub-directory has been changed. And then it sends the file using
>> PUT. The server will respond a 201 Created Response and then terminate the
>> connection. Currently, I haven't found any application layer chunking, all
>> the segmentation are performed by TCP.
>> >
>> >3. Every time I delete (or rename) a file locally, the client will also
>> open a new TCP connection to send several PROPFINDs to find out which file
>> has been removed (or renamed). Then it will send DELETE (or MOVE). The
>> server will respond a 204 No Content Response (or 201 Created Response) and
>> then terminate the connection.
>> >
>> >4. I open a file and frequently edit and save it (actually this is what I
>> usually do with the Dropbox). The client will send the whole file to the
>> server every time I save the file.
>> >
>> >To summarize, it seems that the ownCloud makes heavily use of PROPFIND to
>> achieve the sync process. Each sync operation (e.g. upload, modify and
>> etc.) will start with sending one or more PROPFINDs. And currently, if I
>> add a file to the server (directly from the server side via web interface),
>> the client cannot find the change. I need to interrupt the sync and recover
>> it to make the client be aware of the change and download the newly added
>> file. I'm not sure whether this is caused by the sync mechanism or an
>> improper server configuration. I need to investigate this further and also
>> how the ownCloud works for multiple clients (or devices).
>> >
>> >For ISS, I think ownCloud has demonstrated to some extent that similar
>> IETF protocols could be deployed and employed. The intention of this
>> message is to investigate the current state of using WebDAV for sync
>> purposes to see what needs to be improved here and whether we need new
>> protocols.
>> >
>> >Comments are welcome : )
>> >
>> >Regards,
>> >Linhui
>> >
>> >
>> >_______________________________________________
>> >Storagesync mailing list
>> >Storagesync@ietf.org<mailto:Storagesync@ietf.org>
>> >https://www.ietf.org/mailman/listinfo/storagesync
>> >
>> _______________________________________________
>> Storagesync mailing list
>> Storagesync@ietf.org
>> https://www.ietf.org/mailman/listinfo/storagesync
>>
>