[Storagesync] Some preliminary investigations on ownCloud

Linhui Sun <lh.sunlinh@gmail.com> Wed, 25 November 2015 14:45 UTC

Return-Path: <lh.sunlinh@gmail.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 6C0301B2D91 for <storagesync@ietfa.amsl.com>; Wed, 25 Nov 2015 06:45:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.701
X-Spam-Level:
X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 fD4qy2nKWwAu for <storagesync@ietfa.amsl.com>; Wed, 25 Nov 2015 06:45:53 -0800 (PST)
Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2BF51B2C35 for <storagesync@ietf.org>; Wed, 25 Nov 2015 06:45:52 -0800 (PST)
Received: by wmec201 with SMTP id c201so73155947wme.1 for <storagesync@ietf.org>; Wed, 25 Nov 2015 06:45:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=h0QAEFYthkGCkpUU93y5d3vbCCpuAzECoj0bHUOolTo=; b=atsAmJBe7BaYnc8Mc2fCZ0yJQVnOuXb0yAhw1ZcQ8DfLGzpV0ogJaS6AiNAeKD5nCC avWekUw2vnRQP7pDWLsLW/9h14a19DOGBtMdhPjQQrvLPm8qGU6baw0rd9YABDLvtKay IXOv6YdhiYWpTBsV2JUmrqahpMNf1IKEEj+qlL+McQD4qFh0nDnfIiqZfI4GXb0wzwh2 QhmKe/ya9rFOWBIVg94EhJg9zc/puI4o+Vli5UJe9VO4Q3J7lyYN7eYkMbTnNAjTrXvM cYfpxp78snBPhMrMU9qiI/Zz9ZLIFAxsL/uLlr+juh2x1FugN6i6El8tLFwz+kqXiFKP KdGw==
X-Received: by 10.28.141.140 with SMTP id p134mr5163107wmd.6.1448462751395; Wed, 25 Nov 2015 06:45:51 -0800 (PST)
MIME-Version: 1.0
Received: by 10.28.27.147 with HTTP; Wed, 25 Nov 2015 06:45:32 -0800 (PST)
From: Linhui Sun <lh.sunlinh@gmail.com>
Date: Wed, 25 Nov 2015 22:45:32 +0800
Message-ID: <CAO_YprZTz+O-e82hsTgMBOLr645jJqbhtVKngubnLhimyfB2cg@mail.gmail.com>
To: storagesync <storagesync@ietf.org>
Content-Type: multipart/alternative; boundary="001a1146a0b0c47a0c05255e83d9"
Archived-At: <http://mailarchive.ietf.org/arch/msg/storagesync/Vdy3zpttGilW0OmZWMrOd8T1byE>
Subject: [Storagesync] Some preliminary investigations on ownCloud
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: Wed, 25 Nov 2015 14:45:55 -0000

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