-
Notifications
You must be signed in to change notification settings - Fork 2.1k
spec: WebDAV Optimizations
The ownCloud clients use the WebDAV protocol (RFC 2518 et al) to access the files on the ownCloud Server, adding sync semantics on top.
When a sync run is performed, the clients need to know which files have changed. This can be achieved through time stamp comparison (dangerous due to clock skews on laptops and virtual servers) or changing hash sums (not an option due to ownClouds storage backend architecture, where some backends allow shared access and at the same time cannot provide hash sums on their own.
There are two naïve approaches to list the remote contents so the sync algorithm can judge what changed: Recursively iterating through all directories (called collections in WebDAV lingo) on the server via PROPFIND
(slow due to roundtrips), or performing a single recursive PROPFIND
with infinite depth (resulting in a potentially huge amount of data on every check).
The ownCloud clients store the server filesystem layout in a local cache, and hence would only be interested in the difference between two consecutive sync runs, which leads to potential for optimization, which is exploited as follows:
Since ownCloud 5, an E-Tag
property is provided by the server for every folder and file as part of its PROPFIND
response, as proposed in RFC4918. As soon as a file changes, the file is assigned a new E-Tag. Likewise, it's folder receives a new E-Tag, as does its parent, etc. This way, the client traffic is reduced to a single HEAD
or PROPFIND
request in case nothing changes.
If something changes, the relevant changes can be quickly evaluated with a few PROPFIND
s for those directories where the E-Tag has changed.
- Server has new file or directory: E-Tag gets assigned, E-Tags of parent directories are modified up until the root directory
- File on server gets deleted: File is deleted, E-Tag of parent directories is modified recursively.
-
File has new file or directory: New entry in client DB is created, without the E-Tag. Once a file has been uploaded to the server via
PUT
, aPROPFIND
is issued to retrieve the E-Tag value and entered into the local sync database (Possible optimization: E-Tag is returned in response to thePUT
request (?)).
...
...