Viele kleine Stücke einer Datei von Server laden - welches Protokoll?



  • Welches Protokoll würdet ihr verwenden, wenn euer Programm viele kleine Stücke einer Datei herunterladen soll? (Server wird ebenfalls von mir entwickelt, d.h. ich bin nicht auf bestehende Server angewiesen -- will aber das Rad auch nicht komplett neu erfinden wenn's nicht sein muss)

    "Klein" heisst dabei so ab ca. 1KB.
    Und "viele" heisst mehrere tausend.

    Die vollständigen Dateien sind dabei relativ gross, sagen wir mal so ca. 5 GB.

    Ich würde gern ein Standardprotokoll verwenden. HTTP würde sich natürlich anbieten, nur ... wie genau?

    Ich sehe folgende Möglichkeiten:

    A: ein standard "partial GET" Requests pro "Stück"
    B: ein GET Request pro "Stück" mit der Range in die URL kodiert
    C: ein GET Request pro "Stück" mit der Range als Query-Parameter
    😨 ein GET Request pro N Stücke mit den Ranges in die URL kodiert
    E: ein GET Request pro N Stücke mit den Ranges als Query-Parameter
    F: ein POST Request pro N Stücke mit den Ranges als Daten

    Das ganze sollte möglichst resourcenschonend für den Server (Netzwerkbandbreite, CPU-Last) sein, und auch halbwegs schnell funktionieren (wenig Round-Trips).



  • E, allerdings würde ich das gleich binär machen.



  • http ist binär 😕 und natürlich A alles andere ist doch schwachsinn!



  • im übrigen unterstützt A auch mehrere ranges, daher ist schon die frage falsch gestellt. :p

    @edit: aber mach dir nichts daraus, ist ja 'nur' webzeugs, da kann sich ja jeder schnell reinfrickeln 😉



  • man könnte sich fragen, wozu ein programm viele stücke einer datei runterladen soll.
    und wieso man die datei nicht gleich auf dem server geteilt bereit hält.



  • cooky451 schrieb:

    E, allerdings würde ich das gleich binär machen.

    Was willst du da Binär machen?



  • gefrog schrieb:

    im übrigen unterstützt A auch mehrere ranges, daher ist schon die frage falsch gestellt. :p

    Hm. Das wusste ich nicht. Das wäre natürlich eine Möglichkeit.

    Ich sehe da nur ein potentielles Problem, nämlich mit Proxies/Web-Caches.
    Es wäre nämlich ziemlich doof wenn durch irgend welche Stellen dazwischen der Range Request mit einem "200 OK" beantwortet würde (statt dem erwünschten "206 Partial Content").

    Kann man hier halbwegs sicher sein dass solche Probleme nicht auftreten werden?



  • hustbaer schrieb:

    Was willst du da Binär machen?

    Nicht HTTP nutzen und ein eigenes Protokoll nehmen, was eben alle Ranges binär überträgt. Scheint mir sogar weniger Fehleranfällig als das ganze Text-Geparse.



  • hmmm...mm...m.. schrieb:

    man könnte sich fragen, wozu ein programm viele stücke einer datei runterladen soll.

    http://en.wikipedia.org/wiki/Remote_Differential_Compression

    und wieso man die datei nicht gleich auf dem server geteilt bereit hält.

    Je nachdem welches Seed-File der Client liegen hat können die "Stück-Grenzen" unterschiedlich ausfallen.
    Und selbst wenn sie vorhersehbar wären wäre es unpraktisch und auch semantisch Quatsch. Das File das "Sinn macht" ist das grosse unzerstückelte, dass zum Abgleich kleine Stücke daraus übertragen werden ist bloss ein "Implementierungsdetail".



  • Ich stimme auch ganz klar für A, das ist das sauberste und im Idealfall wirklich einfach zu implementieren.



  • cooky451 schrieb:

    hustbaer schrieb:

    Was willst du da Binär machen?

    Nicht HTTP nutzen und ein eigenes Protokoll nehmen, was eben alle Ranges binär überträgt. Scheint mir sogar weniger Fehleranfällig als das ganze Text-Geparse.

    Was hat das dann noch mit "E" zu tun?
    Naja egal.

    Eigenes Protokoll dafür verwenden will ich nicht wirklich. Das ganze soll möglichst "offen" sein, d.h. es wäre nett wenn man entweder gleich fertige Server dafür verwenden kann (A), oder zumindest mit relativ geringem Aufwand welche dafür entwickeln (B...F) -- unabhängig von Programmiersprache, OS etc.

    Ebenso wäre es nicht verkehrt wenn fertige Caching-Software damit klar kommt (wie z.B. Web-Caches, sei's jetzt normale oder auch transparente).



  • Es gibt noch dieses SPDY, das Google vorgeschlagen hat.

    http://en.wikipedia.org/wiki/SPDY

    Kenn mich da nicht wirklich aus, hat mich bisher nicht interessiert, wollts nur mal ansprechen, vielleicht findest du da ja irgendwelche Vorteile gegenüber HTTP.



  • Naja, SPDY baut ja auf HTTP auf (bzw. kapselt HTTP Requests) - dann kann ich gleich HTTP nehmen.

    Was wären sinnvolle alternativen zu HTTP? Gibt ja etliche andere File-Transfer Protokolle wie z.B. die ganzen FTP Derivate. Und bevor ich mir die alle selbst durchsehe, vielleicht hat ja noch jmd. einen Vorschlag was noch in Frage kommen würde.


Anmelden zum Antworten