Zitat von
Zacherl:
Mit
ZLib kann man aber doch keine progressive De/Compression durchführen. Das Problem ist, dass sehr viel Zeit drauf geht, wenn man beispielsweise eine 500MiB Datei übertragen will.
Erst testen, dann meckern.
Meine Übertragunsrate (vom Client aus gesehen die Zeit zwischen Anforderung und letztem empfangenen Byte) um 40% (von 6MB/sek auf 10MB/sek) und mir reicht das. Ich habe mit wesentlich schnelleren Kompressionsalgorithmen experimentiert, aber
zLib hat das beste 'Geschwindigkeit/Kompressionsrate'-Verhältnis.
ZLib basiert (glaube ich) auf LZW, und das ist schon recht flott.
Eine 500MB Datei würde also z.B. unkomprimiert ca. 100 Sekunden benötigen. Inklusive Kompression ist sie aber in ca. 60 Sekunden empfangen. Ok, nicht berauschend, aber ausreichend, oder?
Zitat von
Zacherl:
Daher soll die Kompression und die Übertragung, bzw Dekompression überlappend stattfinden.
Ich kann mir vorstellen, das man mit
ZLib eine 'progressive' (falsches Wort: überlappend/overlapped wäre besser) Kompression/Dekompression hinbekommt. Der Kompressionsalgorithmus ist straightforward, also könnte man den Output sofort in den
TCP-Stream packen. Ebenso auf der Dekompressionsseite. Der einfachste Ansatz wäre der, die 32KB Blöcke, die man in ZCompressStream verwendet, direkt zu verschicken...
Stimmt, ist eigentlich eine gute Idee. Vermutlich würde die Datenrate noch weiter steigen...