Try this demo for yourself:
1. Run "ping google.com" from another computer on your LAN.
2. Upload a 10-20MB file via Gmail or Dropbox from your computer.
3. Watch the ping times on the other computer skyrocket from around 100ms to upwards of 5-10 seconds.
4. Try a Google search from any other computer on your LAN while this is happening.
As an example, Apple's software update actually uses a variant of LEDBAT (the delay sensitive congestion avoidance algorithm from BitTorrent's protocol) when downloading software updates to avoid inducing bufferbloat in the downlink.
I guess getting things into the server stack can roll out slowly, with very limited and spotty adoption.
Browser support on the other hand...
Well, need I continue?
Suffice to say, that even without the open warfare between rival browser projects, and nightmare-mode security vulnerabilities in common browser plug-ins, it will only make a difference if hundreds of millions of users actually latch onto a new protocol, before it becomes something of a norm.
It's very domain specific and relies on GCP's JSON API so probably isn't suitable to apply broadly.
But why a totally new protocol? Why not use bittorrent, rsync, or even ftp? A lot of effort has gone into making those reliable in the face of network congestion. Trying to shove a lot of bits down a single TCP connection with no traffic shaping is just asking for bufferbloat to strike.
HTTP also has the advantage of being allowed through virtually every firewall.
It seems that webapps are paving the way of the future, for better or worse.
- be sure that browsers and servers already speak it (so small additional libraries required on both ends)
- gracefully degrade to regular form POSTs should tus support not be possible (IE8, etc)
- easily write hooks for progress bars, and e.g. encoding of the uploaded material
- use existing holes in firewalls. FTP requires many ports (for PORT, DATA, PASV) that are blocked on airports, public libraries, large corporations
- add existing HTTP components to make tus better (loadbalancing, intrusion detection, auth, proxies, etc). Some of these apply to FTP as well, but the HTTP options are more (advanced).
Bittorrent is not really client-server oriented, which is what this protocol is trying to solve. Rsync has many the same disadvantages as FTP listed above.
As for a single TCP connection with no traffic shaping, tus support splitting up a file into multiple parts and uploading them in parallel (as regular tus uploads, so profiting from checksums, retries, and resumability) and stitching them together on the server-side by issuing a 'concat'. This means you can have as many connections as you like, and the individual chunks can complete in any order as well.
Traffic shaping is not part of the protocol. By default tus should saturate available connections.
That said we're writing down some recommendations in a separate 'developer guide' document that offers best practices for implementing and deploying tus, traffic shaping could be part of it. Feel free to weigh in here https://github.com/tus/tus-resumable-upload-protocol/pull/68
edit: Looks like someone's already done that: https://github.com/vayam/brewtus (found on http://tus.io/implementations.html, which also has links to Ruby, PHP and CoffeeScript server implementations, and Qt C++, PHP, Go, and Python clients)
That said we're writing down some recommendations in a separate 'developer guide' document that offers best practices for implementing and deploying tus, traffic shaping could be part of it. Feel free to weigh in here https://github.com/tus/tus-resumable-upload-protocol/pull/68
Furthermore, browsers can open only a maximum number of connections at the same time (I believe the maximum on some browsers is even just 2). What if the application already uses one connection for a websocket? Will there be only 1 connection left for the upload? And what if the browser needs to download other resources in the background, such as images, fonts, etc.?
Just some concerns, good luck with the project :)
Currently using AWS API for resumable uploads here.
None of the current core members have experience running Java servers in the real world so it's hard to see what would be involved. We're definitely open to discussing it in the issue if you like.
Might be relevant. https://tools.ietf.org/html/rfc6648
The only exception is X-HTTP-Method-Override, as people have been standardizing on this, and the header is specifically meant to let people deploy tus in environments that don't support all of HTTP and are apparently hard to change.
While NSURLSession does support resumable downloads, it isn't able to resume uploads.
The needNewBodyStream: delegate is the closest thing, and that is called when first uploading from an NSInoutStream or when a transmission error occurs for an idempotent request, or an auth challenge occurs when some of the stream has been sent. (Streams cannot be rewound.)
Background NSURLSessions can take a file reference to upload, and ideally will perform the upload "at a good time", hopefully while charging and connected to a stable network. (But it won't resume an upload, just retry if possible.)
Disclaimer: I'm "involved", but not speaking for any parties involved. Mostly because I don't get invited to those sorts of parties.
