Live data from Hacker News

Tus.io: Open Protocol for Resumable File Uploads

tus.io

31–32 of 32 posts

Re: Tus.io: Open Protocol for Resumable File Uploads

#31
post #30
post #26

Earlier quoted context omitted.

Hi, one of the authors here. It would, but traffic shaping is not part of the protocol itself and by default tus will 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…

I think traffic shaping is very desirable when using a websocket for a separate command-channel. The last thing you want is an upload blocking all communications over that command-channel. 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…

Some valid concerns indeed! You may run dedicated uploading infra which allows more connections (different subdomain/IPs), but it's something we want to be explicit about in our developer guidelines, I'll also see if we can make traffic shaping part of the js browser implementation, as this seems to need it most - thanks!

Re: Tus.io: Open Protocol for Resumable File Uploads

#32
post #28

The 100-Continue idea mentioned in the 3 year old top comment seems like a much better idea. The issues on the tus issue tracker seem to discard this prematurely.

Hi, one of the authors here. 100 Continue wasn't discarded that quickly and is part of the protocol. More info here: https://github.com/tus/tus-resumable-upload-protocol/issues/...

I saw that issue. As I read it, it discards using 100 continue to solve the original problem.
Post reply on HN