Hallöchen erstmal,

Ich möchte in meinen Netzwerk-Protokoll eine optionale Kompression der Daten beim Senden von Dateien einbauen. Dabei habe ich folgendes Problem:

Also komprimieren funktioniert schon wunderbar, will es aber verbessern:
Ich habe eine feste Daten-Nutzgröße von 1350 Bytes. Diese möchte ich so voll wie möglich kriegen um das Netzwerk möglichst auslasten zu können. Wenn ich jetzt die Kompression einschalte, wird folgende Funktion vor dem Senden bzw nach dem Empfang ausgeführt (benutze zLibEx122):

zusammenfalten · markieren

Delphi-Quellcode:

function FileMode_CompressData(var Data; Size: word; Compress: boolean): word;
// Data: die eigentlichen Daten
// Size: die Größe von Data
// Compress: wenn TRUE, sollen die Daten komprimiert werden, ansonsten sollen sie dekomprimiert werden
var
  OutData: Pointer;
  OutSize: integer;
begin
  try
    if Compress then
    begin
      ZCompress(@Data, Size, OutData, OutSize, zcMax);
      // nur wenn die Größe der Komprimierten Daten kleiner ist,
      // sollen die komprimierten auch benutzt werden
      if OutSize < Size then
         CopyMemory(@Data, OutData, OutSize);
      result := OutSize; // neue Größe von Data zurückgeben
    end else
    begin
      ZDecompress(@Data, Size, OutData, OutSize);
      CopyMemory(@Data, OutData, OutSize);
      result := OutSize;
    end;
  finally
    if OutData <> nil then
       FreeMem(OutData);
  end;
end;

Jetzt kann es sein, dass Data nicht mehr 1350 Byte groß ist, sondern z.B. nur noch 816 Byte. Dadurch wird meine Paketgröße von 1350 aber nicht voll ausgenutzt. Was ich jetzt suche, wäre eine Funktion, die folgendes macht

markieren

Delphi-Quellcode:

Comp := TCompressionStream.Create(ms, zcMax);
while ms.Size < 1350 do // <<<<----- !!!! DAS FEHLT MIR - DIE AKTUELLE, UND ZWAR DIE WIRKLICH AKTUELLE GRÖßE VON ms
  Comp.Write(c, 1); // ein weiteres Byte einfügen

Ich kann die Funktion so bereits benutzen, doch da zLib intern mit einem Puffer von 65535 Byte arbeitet, hat ms nach dem Beenden der Schleife immer eine Größe von 65535 Bytes, was wohl etwas zu groß ist.

Ich weiß nicht ob es rein Theoretisch möglich ist, nur die ersten 1350 bytes des Streams dann zu benutzen, doch die Rechenzeit für die übrigen 64185 Bytes benötigt wird, die immer für die Katz wären, sind mir einfach zu Schade

Falls jemand eine Idee hat, wie ich das Problem lösen könnte, wäre es sehr supi, wenn er mir das zeigen könnte

hmm, ich versteh nicht ganz das problem. was spricht dagegen erst die daten komplet zu comprimieren und dann die fertig komprimierten daten stückenweise zu senden?

Das mit den komprimierten Daten stückchenweise schicken hätt ich ja schon längst gemacht, nur das Problem ist was anderes:
Das Protokoll unterstützt den Download von mehreren Quellen, also von mehreren Servern. Eine Datei wird in dazu zuerst in mehrere Parts unterteilt. Jetzt wird vom Clienten eine Anfrage der Daten des Parts X gesendet. Der Server antwortet dann mit den Nutzdaten (und den Protokoll-Headern natürlich). Es kann aber sein, dass Server 1, der Part X senden soll, Part X+1 noch nicht fertig hat (p2p ala BitTorrent). Wenn ich jetzt Part X anfordere, würde Part X+1 mitgesendet, aber Part X+1 ist ungültig, worurch später Part X+1 nochmal heruntergeladen werden müsste.
Wenn der Client bereits Part X+1 heruntergeladen hat, würde dieser somit nochmal heruntergeladen, was auch schwachsinnig wäre. Somit darf der Server nur genau Part X senden, nicht mehr!