Hey,

ich habe mal eine Frage bezüglich der sogenannten on-the-fly Kompression. Und zwar: Kennt jemand einen Komprimierungs-Algorithmus, der dies effektiv unterstüzt? Meine halt nicht sowas wie ZIP, was bei Datenmengen bis maximal 4KiB ja nicht sehr effektiv ist.

Dann die zweite Frage dazu: Gibt es irgendwo ein Beispiel welches das Ganze anhand der Sockets demonstriert. Naja fürs Empfangen ist das ja kein Problem, da die Pakete sowieso durch ein eigenes Protkoll richtig zusammengesetzt werden müssen. Dann kann ich die entreffenden Datenpakete auch gleich dekomprimieren.

Fürs Senden hätte ich jetzt aber keine Idee, wie ich die Datei sequenziell komprimieren und schicken kann, ohne gleich ein eigenes Buffering vorzunehmen, sprich: Die Daten in kleine z.b. 2KiB große Pakete einzuteilen. Diese Arbeit machen die Sockets denke ich schon recht zuverlässig ..

Gruß

Hi Zacher,

mit einer LZ77-Koprimierung oder ähnlichen kannst du sogar schon anfangen zu dekomprimieren, wenn die Daten nur zum Teil eingetroffen sind.

MfG,
Bug

Ist dies der einzige Algorithmus bei dem sowas geht? Weil laut Wikipedia Beschreibung ist er ja weder in der Kompressionsrate noch in der Geschwindigkeit so toll

Interessieren würde mich zudem ein Verfahren, welches auch parallel die Daten komprimiert und die bereits komprimierten Daten sendet.

Ich hab zlibEx für meine Socketübertragung verwendet. Der ist schnell und sehr effektiv. die Übertragungsrate stieg um ca. 40-50% gegenüber der unkomprimierten Übertragung.

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.
Daher soll die Kompression und die Übertragung, bzw Dekompression überlappend stattfinden.

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.
Daher soll die Kompression und die Übertragung, bzw Dekompression überlappend stattfinden.

ja aber du könntest es ja so machen:

ersten 20KB der datei nehmen
diese 20kb packen
übertragen
empfänger entpackt (während das nächste 20KB packet kommt)
...

Das stimmt wohl, aber so wie ich die ZLib Kompression verstehe wird diese desto effektiver, je mehr Daten auf einmal komprimiert werden =/

Kann man denn wenigstens die Buffergröße der Sockets auslesen, damit ich die Pakete daran anpassen kann?

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...

Zitat:

Kann man denn wenigstens die Buffergröße der Sockets auslesen, damit ich die Pakete daran anpassen kann?

Wenn es dir hilft:

Die WinAPI kennt getSockOpt (Unit WinSock)

markieren

Delphi-Quellcode:

len:=4;
getsockopt(aSocket, //Socket-Handle
           SOL_SOCKET,
           SO_SNDBUF, //bzw. eben SORCVBUF
           @I_optvalue, //Buffer: hier integer fürs Ergebnis
           len); //länge des Buffers

@alzaimar: War kein Meckern ..

Danke euch allen, werde es dann mal mit ZLibEx probieren.