Re: [Storagesync] Some preliminary investigations on ownCloud

[Linhui Sun <[e-mail]>]

Hi Fei,

2015-11-26 11:11 GMT+08:00 Fei Song <[e-mail]>:

> Hi all
>
>
> --------------
> Fei Song
> >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.
>
> I wonder whether these message you got had been encrypt or not.
>
The ownCloud suggests people use HTTPS, but you could also use the HTTP.
And that is what I did.

>
> >
> >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).
>
> What do you mean by "directly from the server side via web interface".
> If all the configuration were correct, do you want to identify that the
> sync in
> ownCloud is only unidirectional?
>
People could access to the ownCloud service via desktop, mobile client or
web interface (i.e. browser), the point I want to say here is an operation
on the server side cannot be detected automatically. I'm not sure whether
I've configured the server correctly. But the sync is not unidirectional
since after I recovering the sync, the client could download the asap.

>
> >
> >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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/storagesync
>