As you probably have noticed by now, we are currently modernizing ownCloud from the ground up, which already took a while since we announced our plans for ownCloud Infinite Scale. But have no fear, it’s well worth the wait. Our goal is infinite scale, hence the name. Infinite scale means an infinite number of files, users and machines as well as infinite file sizes. We write it in Go, making ownCloud platform independent. ownCloud Infinite Scale neither requires Apache nor any PHP infrastructure, becoming the most easy-to-use and most easy-to-deploy ownCloud ever. We use microservices and a three-tier architecture, making ownCloud a secure cloud native solution to file access requirements. Some globally well-known research institutions are involved in the creation of ownCloud Infinite Scale, making sure it extends their capabilities as it will yours.
One of the tangible ways in which ownCloud Infinite Scale enables, well, infinite scalability is by using tus.
Why ownCloud Infinite Scale uses tus
Remember when you last uploaded a very large file only for the upload to stop unexpectedly, requiring you to re-upload from scratch, wasting your time? To make sure this experience is soon a thing of the past, there is the tus protocol, an open-source endeavor to enable resumable file uploads, based on HTTPS. Members of the ownCloud team contributed code to tus and we use it for uploads into ownCloud Infinite Scale.
What it does
tus is implemented in ownCloud Infinite Scale to enable infinite file sizes, although technically, there is a limit: 8 Exabyte. tus enables infinite flexibility to pause uploads and later resume where you left off. tus helps ownCloud make mobile work more resilient, offsetting the fragility of mobile networks. Just think about syncing a boatload of files while on a high speed train that runs through many tunnels. Or think about using a popular DDoS mitigation service that restricts uploads to certain size limits like 100MB.
How ownCloud Infinite Scale uses tus
tus takes a trivial upload and breaks it down into a nifty chain of different HTTPS requests. First, the client sends an upload creation request to initiate the upload, to which the server returns an upload URL to identify the resource. Then, the client sends a patch request to the upload URL containing the actual upload content and the upload-offset header to tell the server at which place in the file the uploaded data should be written. In case the upload gets interrupted, the client sends a head request to the upload URL asking the server for its current upload-offset of the file. Then, the client can send a new patch request with the relevant data chunk to complete the upload. Or, in case of a patchy connection, advance the upload somewhat, leading to another iteration of a head request followed by a upload-offset answer from the server followed by a patch request from the client. Sooner or later, all data constituting the file should be written to the upload URL, completing the upload. Unfinished uploads can be resumed or are cleaned up after a certain time period (configurable, by default after 24 hours). If an upload chunk size is set in the server configuration, uploads are automatically chunked accordingly. Oh, and all of that usually happens faster than you can read this paragraph, depending on your uplink speed.
tus is part of the upcoming ownCloud Desktop 2.7 release and already integrated in the iOS app as a tech preview. It will be part of the new web interface for ownCloud that is currently in development. So users of all the current ownCloud apps will be able to, in parallel to using ownCloud 10, seamlessly transfer data to an ownCloud Infinite Scale Server, using tus.