Vimeo gaat 'resumable upload'-protocol van Nederlandse start-up gebruiken

Videodienst Vimeo gaat gebruikmaken van tus 1.0, een open protocol voor resumable uploads, dat in gang is gezet door het Nederlands-Duitse bedrijf Transloadit. Momenteel zijn er vele gesloten methodes voor het hervatten van uploads, maar tus moet daar verandering in aanbrengen.

Vimeo is de eerste grote organisatie die tus gaat gebruiken. Een ontwikkelaar van Vimeo is nauw betrokken geweest bij het project. Tus maakt het mogelijk efficiënt te uploaden, ook via mobiel, waarbij bestanden niet verloren gaan vanwege netwerkproblemen, maar uploads hervat worden zodra er weer verbinding is. Het protocol werkt als extra laag bovenop http, met alle voordelen van dien, en beschrijft het hervatten van een onderbroken upload. Clients en servers moeten het protocol implementeren. Een dergelijk protocol zou nodig zijn, nu steeds meer mobiele gebruikers grote foto- en videobestanden online willen zetten, maar de uploadverbindingen daar niet linear mee vooruit zijn gegaan.

Tot nu toe bleef het protocol redelijk onder de radar, maar er is twee jaar gewerkt aan versie 1.0, dat op korte termijn moet verschijnen. Het protocol is in gang gezet door het Nederlands-Duitse bedrijf Transloadit, dat het zelf gebruikt voor zijn dienst voor file-uploads en bestandsconversie. Het bedrijf besloot echter het protocol te openen en de community er via GitHub verder aan te laten werken.

"We hadden het voor onszelf kunnen houden, maar was het dan zo uitgebreid geworden? Ik denk het niet", zegt Transloadit-oprichter Kevin van Zonneveld tegen Tweakers. Volgens hem is het een probleem dat er teveel verschillende implementaties voor het hervatbaar uploaden van bestanden zijn. "S3 biedt iets in deze richting, resumable.js, plupload, enzovoorts, maar iedereen doet het net weer even anders." De grote cdn's als Akamai en diensten als Dropbox hanteren hun eigen gesloten platformen en er zijn commerciële op udp gebaseerde diensten als die van Aspera. Het enige open protocol is van Google, maar de functionaliteit daarvan is zeer beperkt en biedt geen platform voor het aandragen van verbeteringen.

Versie 1.0 van tus krijgt tal van geavanceerde eigenschappen, zoals de mogelijkheid voor clients om de configuratie van servers te herkennen. Daarnaast komt er ondersteuning voor checksums, retries, vervaltermijnen van uploads en metadata-extensies. Belangrijkste toevoeging is concatenation, waarmee grote bestanden parallel in delen te uploaden zijn.

"Dus als je een bestand van 100GB moet uploaden", legt Van Zonneveld uit, "heb je kans dat je connectie niet optimaal benut wordt vanwege onder andere de tcp-overhead. Dankzij concatenation kun je twintig bestanden van 5GB uploaden, waarbij een server met tus-ondersteuning ze samenvoegt. Voordeel is de snelheidswinst en het feit dat elk bestand-deel individueel profiteert van tus-functionaliteit als checksums en auto-resume."

Transloadit is in gesprek met meerdere partijen over tus-ondersteuning en gaat de adoptie in alle grote programmeertalen promoten bij Googles Summer of Code.

Reacties (40)

Waarom niet gewoon FileTransferProtocol gebruiken? Die ondersteund al 1000 jaar hervatten van up&downloads.

1. Rechten - een FTP verbinding werkt met een bepaald stappenplan (inloggen, ophalen van inhoud, uploaden). Dit zou betekeken dat je voor elke gebruiker een random account en wachtwoord moet aanmaken. Waarschijnlijk kun je hier wel omheen werken, maar waarom moeilijk maken als het ook makkelijker kan?
2. Extra infrastructuur - als je al een complete HTTP omgeving hebt, is het waarschijnlijk makkelijker om er een laag overheen te leggen. Voor FTP moet je een hele aparte infrastructuur opzetten (we hebben het namelijk bij grote partijen zoals Vimeo niet over 1 lullig FTP servertje).
3. Firewalls - FTP is niet het meest eenvoudige protocol om werkend te krijgen over meerdere NAT lagen. Uiteindelijk kom je met PASSIVE mode heel ver, maar ook hierbij geldt: waarom ingewikkeld doen als het makkelijker kan?

1. Anonymous.
2. Of je nou tus of ftp gebruikt, beide vereisen een infrastructuur. Maar tus heeft zo te lezen wel meer up-to-date eigenschappen dan ftp.
3. Nonsens, als is het maar dat bedrijven echt geen nat gaan gebruiken voor dit soort diensten. Ftp poorten open zetten naar een server of tus poorten open zetten naar een server lijkt mij geen verschil maken.

Ik heb net effe de protocoldocumentatie doorgebladerd en de source page van het voorbeeldje bekeken.
3. Er hoeft bij tus geen poorten geopend te worden. Het werkt boven op het HTTP protocol. Dat betekent dat het geïmplementeerd kan worden op bestaande HTTP servers zoals Apache en IIS. Ook de client moet tus ondersteunen dus dat betekent extra

<script src="/assets/js/jquery.tus.js"></script>

javascript in de webbrowser.

2. De extra infrastructuur is dus minimaal. Een stukje javascript en een webservermodule, bijvoorbeeld via node.js of als Python of PHP implementatie.

1. Zelfs anonymous zit de rechtenvraag bij FTP in de weg; want er wordt nog altijd om een login gevraagd. Dat je daar 'anonymous' kan invullen neemt niet weg dat een gebruiker extra handelingen moet verrichten om z'n bestand geüpload te krijgen. Nog even daar gelaten of het goed mogelijk is de upload van de ene anonieme gebruiker onzichtbaar te houden voor de tweede anonieme gebruiker die inlogt... tus is in ieder geval zeker een-richtingsverkeer.

[Reactie gewijzigd door jiriw op 20 februari 2015 16:41]

Mijn reactie was op eborn om vooral aan te geven dat ftp implementeren niet veel anders of moeilijker zou moeten zijn dan tus. Tuurlijk zijn er verschillen en is tus geschikter, maar daar ging mijn post niet om.
1. Dat je anonymous in moet vullen houdt niet in dat je als gebruiker een extra handeling, de login, moet doen. Dit implementeer je in de software, op net zo'n manier als dat je in ftp programma's anonymous aan kan vinken als user en het pogramma automatisch inlogt als anonymous.
2. Een stukje tus software of een ftp service, voor beide is de infrastructuur minimaal.
3. Ok, voor ftp moet je extra poorten open zetten, maar ik kan me niet voorstellen dat dat nou zoveel werk is.

Verder kan ik nog toevoegen dat je voor ftp net zo goed de login van je account kan gebruiken., dan hoef je anonymous niet eens te gebruiken als dat voor sommige niet volstaat.

Maar nogmaals, het gaat niet om de details hoe je beide moet implementeren, het gaat erom dat voor beide een minimale inspanning nodig is om het te implementeren en dat dat niet zo veel verschil maakt als dat eborn doet lijken. En tuurlijk zoals ik al zei, tus is veel geschikter en moderner dan ftp.

Poorten openzetten in beide richtingen is naar keus weinig werk of op netwerkniveau zo goed als onmogelijk/ongewenst. Nog los van het ontbreken van fatsoenlijke authenticatie- en beveiligingsopties in het FTP-protocol zelf. De meeste gevallen vallen onder dat onmogelijk/ongewenst, tegenwoordig. En terecht, het was ooit een prachtig protocol omdat er geen betere waren maar wordt zelfs al jarenlang links en rechts ingehaald door SFTP en SCP die hooguit een enkel extra poortje gebruiken en gewoon met SSH-authenticatie werken. Als je vandaag den dag nog een nieuw systeem opzet met een legacyprotocol zoals FTP, zal je niet moeten beginnen zoals jij doet met vragen waarom het niet zou kunnen maar moeten verdedigen waarom je juist nog FTP zou willen gebruiken. Zelfde categorie als een rlogin (wie kent het nog?) of telnet toegang tot een server die rechtstreeks aan het internet hangt.

[Reactie gewijzigd door mae-t.net op 21 februari 2015 18:36]

FTP kan ook anonymous, verder is het FTP protocol al lang uitgevonden en dus breder inzetbaar doordat het al breder beschikbaar is.

Daarnaast gaat het niet om de nat bij de bedrijven als vimeo, maar om de nat bij de gebruikers...

Vimeo gaat even een anonymous FTP open zetten op hun server waar jan en allemal op terecht kan? Dan zullen ze na een paar dagen wel een leuke collectie aan illegale software en andere rotzooi hebben staan

Het gaat niet om de bedrijven die NAT gebruiken, maar de consument c.q. eindgebruiker die achter een willekeurige router (of meerdere) zit.

Dat klopt, dat zullen ze niet doen, maar qua implementatie werkzaamheden hoeft ftp niet onder te doen voor tus. Tuurlijk is tus moderner en geschikter voor uploads, ftp is nooit met die gedachte gemaakt.

Of je nou tus of ftp over je nat router gebruikt zou niet uit moeten maken, nat verzorgt dat allemaal zelf.

Bij Vimeo kan je ook kiezen voor FTP als je gaat uploaden, maar wel alleen als je Pro-member bent.

https://vimeo.com/help/fa...-vimeo/uploading-with-ftp

Tja... http://mywiki.wooledge.org/FtpMustDie

Neeee, dat is niet 1000 jaar hé, dat was ergens in 1971. Dus ongeveer 44 jaar geleden.

Heb je een bron? 1000 lijkt me toch aannemelijker.

Zou ik dit ook kunnen gebruiken voor het overdragen van bestanden/project mappen in een eigen netwerk. Of is dit meer gemaakt voor implementatie op grotere infrastructuur

Denk dat het onafhankelijk van het netwerk formaat is.
Dus net als je nu een ftp/http server kan hebben thuis, kan je ook een tus server hebben thuis.

Gebruik Robocopy onder Windows. Die ondersteund het hervatten van onderbroken kopieeracties.

Het idee was volgens mij juist om geen gesloten platformen meer te gebruiken. Maar bedankt voor de tip

tus gaat via http, het is namelijk een laag boven op http. Dit houd in dat je dan ook op je computers een webserver moet draaien die tus support en een webinterface moet bouwen om het te kunnen gebruiken. Ik persoonlijk zou het niet doen, maar een ander systeem zoeken.

Net Even gekeken, maar echt veel activiteit is er niet op Github. Verder snap ik niet dat de front-end javascript Library afhankelijk is van JQuery.... Waarom??? Niet iedereen hoeft meteen JQuery in te laten omdat ze alleen dit 'protocol' willen gebruiken. Het is alleen maar een dependency die de pagina extra zwaar maakt, een extra http-request kost en de laadtijd verlengd.

Verder hebben ze een server in GO geschreven, of iemand dit ooit gaat gebruiken... Had je tijd in een Apache of NGinX module gestoken. Een server word gekozen omdat mensen er vertrouwd mee zijn. Veel hostingproviders hebben ook alleen maar Apache.

Verder zijn de libraries voor php, node en dergelijke ook al een jaar oud. Deze zijn dan ook al niet echt aantrekkelijk om te gebruiken.

Het zou wat kunnen gebeuren, maar dan moet er nog een hele hoop gebeuren.

[Reactie gewijzigd door Anoniem: 604167 op 20 februari 2015 20:08]

In welke branch heb je gekeken? In 1.0 is veel activiteit, ook in de issue tracker. Wat betreft implementaties, dat is niet aan de protocol schrijvers maar aan programmeurs die het protocol interessant vinden. De protocol schrijvers zullen wel de jQuery & Go voorbeelden up to date maken voordat 1.0 uitkomt en als mentoren optreden tijdens Google Summer of Code om implementaties in de andere talen naar 1.0 te krijgen.
Zoals te lezen was in https://github.com/tus/tu...ocol/wiki/gsoc-2015-ideas krijgt Nginx daar ook aandacht. Maar inderdaad, het blijft open source.

Het hangt er maar vanaf wat je 'veel activiteit' noemt. 14 dagen geleden de laatste commit noem ik niet echt veel.

Waar ik echt benieuwd naar ben is de snelheid die jullie halen bij uploaden over een secure verbinding, Wij hebben users, die een paar keer per week bestanden uploaden van 200-400MB. Dat moet (a) secure, (b) resumable, (c) scriptable/command-line driven en (d) snel. De cUrl sftp upload speed is notoir slecht, https uploads zijn niet resumable, dus die beide vielen af. We hebben ook gekeken naar ftps en scp. Ook slechte performance of niet resumable. Na veel zoeken zijn we uitgekomen op lftp als client en een sftp-server met alleen write en append rechten. Ergens in de 30.000 uploads tot nu toe kwam het resumable echt tot zijn recht: een user die een bestand van 500MB over 6 verschillende, achtereenvolgende internetverbindingen uploadde.

Met lftp als client haalden we over sftp snelheden die gelijk waren aan die van een niet-secure ftp-verbinding. Als jullie over https hogere snelheden halen, zou het voor ons interessant zijn om naar tus te gaan kijken. Hebben jullie de snelheid van tus-uploads wel eens afgezet tegen een upload over plain ftp?

[Reactie gewijzigd door Jan-E op 21 februari 2015 10:20]

Leuke van een protocol op basis van http is dat je extra software of appliances zou kunnen inzetten. Denk daarbij aan authenticatie, reverse proxies, maar ook het toevoegen/offloaden van SSL is eenvoudig, en een standaard optie in de ELB van Amazon om eens wat te noemen.

De kale doorvoersnelheid zal per taal & implementatie verschillen. Met de Go implementaties die we zelf schrijven verwachten we in ieder geval dat met de Concatenate extensie, je schijf en netwerkverbinding eerder beperkende factoren zullen worden dan je CPU of tus.

Als je de eerste versies proef wilt draaien, neem even contact op!

Wat betreft de activiteit, die zit hem bij het schrijven van het protocol minder in het aantal commits en meer in de research en discussies die daaraan vooraf gaan in de pull requests, issues, chat.

Ja, en als je zoveel nodig hebt dan is het wel iets anders dan een protocol. Maar aangezien ze ook plupload noemen; het lijkt me gewoon een alternatief daarvoor. Plupload lijkt me prima, tus...

Als ik 't nou heel simplistisch bekijk (na het lezen van een aantal commentaren): Bespeur ik nou eigenlijk een beetje torrent-protocol in de manier van uploaden? (samenvoegen, hash, resumable, extra http-laag)

Een belangrijk onderscheid is dat bittorrent voor peer-to-peer distributie van bestanden zorgt waarbij alle nodes min of meer gelijk zijn. Dit neemt centrale bottlenecks weg en is dus heel geschikt voor het verspreiden van bijvoorbeeld installatie dvds Als client, help je ook andere clients aan hun dvdtje.

Bij tus is er sprake van een klassieke client / server verbinding, waarbij de client in dit geval de server 'bevoorraadt'. Een ander belangrijk onderscheid is dat tus als extraatje bovenop http werkt en daarnaast dus geen eigen poort nodig heeft. Een klein stukje extra javascript en php code toevoegen aan bestaande websites is in principe voldoende voor een werkende tus verbinding tussen webbrowser en server in het datacenter.

Al zal in het geval van de server de voorkeur meestal uitgaan naar een dedicated programma in Go, C, Node.js, Haskell, Erlang, etc. Omdat die talen hier iets beter geschikt voor zijn - en men er van kan uitgaan dat de tus server wordt gerund door professionals die op schaal opereren (zoals Vimeo) en dus de middelen, en er baat bij hebben zo efficient mogelijke server programma's te gebruiken.
In de vergelijking klopt het overigens wel dat zowel tus als bittorrent een bestand in stukjes kan hakken en die delen gelijktijdig kan verzenden. Geen appels met peren dus inderdaad

[Reactie gewijzigd door kevinvz op 21 februari 2015 13:34]

Dat je geen extra poort nodig hebt is zeer zeker een voordeel. In onze uploadtool hebben we ook een fallback naar https uploads zitten voor de gevallen waarin poort 22 naar onze server dicht staat en de sftp-verbinding faalt.

Als je tus op kleinere schaal wilt inzetten, loop je echter tegen een andere beperking aan: het aantal IPv4 adressen dat je tot je beschikking hebt. Een dedicated server, die luistert op poort 80 en poort 443, kan alleen maar gerealiseerd worden als je nog een IP-adres hebt waar die poorten nog niet gebruikt zijn. Dat zal bijna nooit het geval zijn.

Je kunt natuurlijk je webserver (Apache met PHP in ons geval, en dan zelfs nog op Windows 2008 R2) het werk laten doen, maar dat schaalt vermoedelijk slecht. Of je moet een reverse proxy voor de webserver zetten die het tus-verkeer scheidt van het normale https-verkeer, maar dat is ook niet ideaal. In de GSOC ideas wordt een Nginx tus module geopperd, maar ik zou daar zeker een Apache tus module aan toevoegen. Zonder ondersteuning binnen Apache wordt uitrol van het protocol buiten de grote spelers problematisch, schat ik zo

Precies wat ik ook dacht, een stukje torrenttechnologie.

Dit kon voor download al veel langer toch? is dat voor uploads dan zo anders?

Even een stomme vraag, maar hoezo is dit nieuws? Genoeg Nederlandse bedrijven maken projecten open source en genoeg grote bedrijven maken daar gebruik van... En als wij een nieuw (ook groot) project begonnen maakte we gebruik van tal van libraries en in het apartste geval levert dat een Twitter berichtje op, niet een full bloem artikel op een nationale nieuws site.

Met andere woorden: kan Tweakers bevestigen dat het geen enkele banden met Transloadit heeft?

Zie hier: http://tweakers.net/info/over_tweakers/onafhankelijkheid

Denk je nou echt serieus dat omdat Tweakers hier een artikel over schrijft het gelijk banden moet hebben met het bedrijf?

Mwah klein detail:
Hosting door True

En wie is een ex-R&D van True? De co-founder van Transloadit

We zijn in 2009 met Transloadit begonnen. Als ik een vinger bij Tweakers in de pap had (wat als medewerker van True al niet zo was, laat staan als oud-medewerker), had je al eerder over Transloadit gelezen

Het is wel zo, dat ik als trouwe Tweakers lezer het nieuws over Vimeo tot dusver alleen aan hen heb laten weten. Maar we zullen zeker ook kijken of andere redacties geïnteresseerd zijn omdat we de exposure goed kunnen gebruiken om meer feedback, testers, en implementaties voor ons protocol te krijgen.

Ik neem wel mijn petje af voor de research en het leggen van dit verband trouwens, oprecht.

Naja, voor zo iets als dit? En dan ook nog die quote van de CEO? En een Nederlands bedrijf? Dan begin ik inderdaad toch wel een beetje te twijfelen. En als google ook nog toont dat niemand andere dit 'nieuws' beschrijft... Zelfs de tus blog zelf heeft het niet hierover... Ja...

Handig als je grote bestanden nodig hebt.

Don't shoot me, maar ik heb deze titel nu al 10 keer gelezen :
"niet optimaal benut Vimeo gaat 'resumable upload'-protocol van Nederlandse start"
maar ik snap er nog steeds geen snars van

Is blijkbaar aangepast, was eerst dit 'Vimeo gaat resumable upload protocol van Nederlandse start-up gebruiken'

niet optimaal benut is een stukje gekopieerd uit de tekst

Zag het ook. Ze hebben het inmiddels gefixed.

Nou, het is een flame richting t.net redactie. Maak jij nooit ergens een foutje? Het direct clickbait noemen..

Maar even on-topic, dit zou nogwel eens handig kunnen zijn als je op vakantie bent en een video aan je familie wilt laten zien, maar je zit met een brakke camping internet verbinding. Ik ga me er zeker even over inlezen, zeer interessant.