[DEC] MD5 Hash großer Datei berechnen ohne Programhänger

[alleinherrscher]

Hi@all

Ich verwende Hagens MD_5 Hash um eine Datei eindeutig identifizieren zu können. Habe eine Dateiübertragung mit Fortsetzung bei Unterbrechung geschrieben. Der Sender berechnet zunächst aus einer Datei einen MD5 Hash, schickt diesen zum Empfänger. Dieser guckt in einer Liste nach, ob der entsprechende Hash schon vorhanden ist, sucht die zugehörige Datei raus, ermittelt die Stream position, schickt diese an den Sender zurück.

Mein Problem ist nur: Bei sehr großen Dateien benötigt das berechnen des Hashes eine ganze menge Zeit. In dieser Zeit ist das Forumlar eingefrohren. Was kann ich dagegen tun? Hagen hat dieses IDECProgress eingebaut. Aber damit komme ich nicht wirklich zurecht (Habe keine Klasse vom Typ TForm). Und einen extra Thread zu programmieren halte ich für übertrieben...


Vielen Dank für eure Hilfe und schönes FUssball Wochenende!

Euer Alleinherrscher

[Luckie]

Um einen extra Thread wirst du dann aber nicht drum rum kommen.

[himitsu]

mal aus interesse: wie groß ist denn eigentlich sehr groß und was ist eine ganze Menge?

[alleinherrscher]

Zitat:

Zitat von himitsu

mal aus interesse: wie groß ist denn eigentlich sehr groß und was ist eine ganze Menge?

sach mal so: mit nem Intel Core Duo T2370 braucht ne 3gb große Datei ziemlich genau 2 Minuten.

@Luckie: Danke, wenn du das sagst, werd ichs wohl doch so machen :)

[sx2008]

Man könnte das so lösen:
TFileStream -> TIntercepterStream -> DEC_MD5
Ich nehme mal an DEC kann einen MD5 über alle Daten eine Streams berechnen.
Würdest du ein TFileStream bereithalten und an DEC übergeben, wäre alles wie bisher.
Jetzt kommt die Klasse TInterceptorStream ins Spiel.
Die Klasse wird von TStream abgeleitet und macht eigentlich nichts anderes als die Aufrufe .Read() und .Write() an ein anderes Stream-Objekt durchzureichen.
Zusätzlich hat es aber die Events OnBeforeRead, OnAfterRead, OnBeforeWrite und OnAfterWrite.
Für diese Event kann dein Prog. einen EventHandler bereitstellen und Application.ProcessMessages aufrufen.

TInterceptorStream gibt es noch nicht; man müsste sie erst noch programmieren.
siehe auch: http://de.wikipedia.org/wiki/Stellvertreter_(Entwurfsmuster)

[alleinherrscher]

Also Hagen löst das Problem so:

Zitat:

unterstützen einen Progress -> IDECProgress Interface. Du deklarierst in deinem TForm zb. sowas

Delphi-Quellcode: markieren
type
TForm1 = class(TForm, IDECProgress)
procedure Process(const Min,Max,Pos: Int64); stdcall;
end;


und kannst du dein Application.ProcessMessages reinbauen. Übrgeben bekommst du Min,Max und Pos das sind die Größen und Datezeiger/Streamtzeiger.

Allerdings ist meine Klasse nicht vom Typ TForm. Ich wusste gar nicht, dass ich bei class() zwei Argumente reinschreiben kann?! Wenn ich allerdings nur "class(IDECProgress)" schreibe, meckert der Compiler, dass es Klassentyp erforderlich ist. Jemand ne Idee, ich ich diesen Code implementiere, wenn ich eine Klasse ohne Vorfahre habe?

Viele Grüße und Danke nochmal

[Dax]

Delphi-Quellcode:

class(TInterfacedObject, IDECProgress)

[alleinherrscher]

Zitat:

Zitat von Dax

Delphi-Quellcode:

class(TInterfacedObject, IDECProgress)

Yeah, thats it!

Wunderbar es funktioniert. Danke Dax! Hier nochmal die zusammenfassung:

1. Eine neue Klasse definieren:

Delphi-Quellcode:

THash_Helper = class (TInterfacedObject,IDECProgress)
    procedure Process(const Min,Max,Pos: Int64); stdcall;
   end;

in die prozedur Process kommt nur ein Application.processmessages

Dort wo ihr den Hash berechnen wollt kommt hin:

Delphi-Quellcode:

  HashHelper1:=THash_Helper.Create;
  pack.MD5_Hash:=THash_MD5.CalcStream(data,data.size,TFormat_HEX,HashHelper1);
  freeandnil(HashHelper1);

Grüße und danke nochmal an alle!

[himitsu]

ok, 3 GB ist schon recht groß

hatte da Aufgrund der Dateiübertragung eher was Kleineres vermutet :stupid:

aber 25 MB/s ... eventuell mal nach 'ner schnelleren Platte schauen :angel2:
(gut, so schlimm ist der Wert nun auch nicht)

also da macht sich ein Thread wirklich gut :angel:

[alleinherrscher]

Zitat:

Zitat von himitsu

ok, 3 GB ist schon recht groß

hatte da Aufgrund der Dateiübertragung eher was Kleineres vermutet :stupid:

aber 25 MB/s ... eventuell mal nach 'ner schnelleren Platte schauen :angel2:
(gut, so schlimm ist der Wert nun auch nicht)

also da macht sich ein Thread wirklich gut :angel:

Die Geschwindigkeit ist vollkommen okay, nur sollte halt das Programm nicht einfrieren dabei :)

//OffTopic:
Es geht mal wieder um Lan.FS (www.lan-fs.de) Denn wenn ein Programm 2 Minuten lang nicht reagiert bekomm ich wieder jede Menge Emails mit dem Inhalt "Hilfe, das Programm funktioniert nicht)

[dominikkv]

Delphi-Quellcode:

  HashHelper1:=THash_Helper.Create;
  pack.MD5_Hash:=THash_MD5.CalcStream(data,data.size,TFormat_HEX,HashHelper1);
  freeandnil(HashHelper1);

ähm... bin mir zwar jetzt nicht sicher, aber ist es nicht so dass man HashHelper1 nicht freigibt weil die Klasse von TInterfacedObject abgeleitet ist und diese einen Referenzzähler hat und wenn der 0 ist sich die Klasse selber frei gibt?

[DGL-luke]

@alleinherscher:
"Zwei Vorfahren in einer Deklaration":

Das ist sogenannte Mehrfachvererbung. Die gibt es in Delphi aber gar nicht. Delphi kann aber (OLE-)Interfaces.
Wenn du darüber mehr wissen willst, solltest du genug finden unter dem Stichwort Interface.

Grob gesagt, beschreibt aber ein Interface was eine Klasse können muss. Um ein Objekt zu benutzen, benötigt man dann nur das Interface und nicht die tatsächliche Klasse, denn das Interface stellt sicher, dass das Objekt alles kann was man braucht.

[Dax]

Zitat:

Zitat von dominikkv

ähm... bin mir zwar jetzt nicht sicher, aber ist es nicht so dass man HashHelper1 nicht freigibt weil die Klasse von TInterfacedObject abgeleitet ist und diese einen Referenzzähler hat und wenn der 0 ist sich die Klasse selber frei gibt?

Ja, aber selbst freigeben kann man trotzdem. Man muss es sogar, wenn man nicht das Interface, sondern das Objekt benutzt (IInterface vs TInterfacedObject).

[alleinherrscher]

Danke Leute, ich werd mir dazu mal was durchlesen :)

[negaH]

Hi

man kann das mit der Hash-Helper Klasse so machen, aber empfehlen würde ich es nicht. Das IDECProgess Interface, obwohl so einfach konstruiert, ermöglicht uns noch viel mehr. 1.) Anwendung nicht einfrieren lassen, 2.) Fortschrittsbalken anzeigen, 3.) aktuelle Aktion kann durch Benutzer sauber abgebrochen werden.
Alle diee 3 Features sind Bestandteile des GUIs einer Anwendung, also sollte man diese Feasture auch darin einbauen, statt separate Klassen zu entwerfen. Denn diese bedeuten nur einen Umweg in der Programmierung, also eher ineffektiv.

Die normale Anwendung sieht so aus

Delphi-Quellcode:

type
  TForm1 = class(TForm, IDECProgress)
  public
    ProgressBar1: TProgressBar;
    procedure ButtonClick(Sender: TObject);
    procedure FormCloseQuery(Sender: TObject; var CanClose: Boolean);
  private
    FAction: Integer;
    FTick: Cardinal;
    procedure Process(const Min,Max,Pos: Int64); stdcall;
  end;


procedure TForm1.ButtonClick(Sender: TObject);
begin
  if FAction = 0 then
  try
    Inc(FAction);
    FTick := GetTickCount;
    Button.Caption := 'Abort';
    try
      with TCipher_Blowfish.Create do
      try
        Init(...);
        EncodeFile(FileName, FileName, Self);
      finally
        Free;
      end;
    except
      on E: Exception do
        if E is EAbort then ShowMessage('aborted by User')
          else reraise;
    end;
  finally
    FAction := 0;
    Button.Caption := 'Start';
  end else Inc(FAction);
end;

procedure TForm1.FormCloseQuery(Sender: TObject; var CanClose: Boolean);
begin
  CanClose := FAction = 0;
  if not CanClose then Inc(FAction);
end;

procedure TForm1.Process(const Min,Max,Pos: Int64);
var
  Tick: Cardinal;
begin
// Fortschrittsbalken
  ProgressBar1.Min := 0;
  ProgressBar1.Max := 100;
  ProgressBar1.Position := Round((Pos - Min) / (Max - Min) * 100); // Anzeige in Prozent
// Antifreeze
  Tick := GetTickCount;
  if FTick + 100 <= Tick then
  begin // nur alle 100ms soll Application.ProcessMessages aufgerufen werden
    FTick := Tick;
    Application.ProcessMessages;
  end;
// Userabbruch
  if FAction > 1 then 
    Abort;
end;

Normalerweise ist es doch so: Ein GUI wird durch Anwender bedient. Das GUI -> TForm -> hat also eine ButtonClick() die die eigentliche längerandauernde Funktion startet. Dem Anwender ist es volkommen ausreichend wenn er zwei Dinge nun parallel machen kann, 1.) er kann die Aktion noch abbrechen, 2.) er kann weiterhin die Anwendung verkleinernen um an sein Onlinegame ranzukommen. Wir müssen also garnicht mit echter Parallelität programmieren, also ohne Threads. Obiger Source zeigt wie mit wenigen Griffen, direkt im GUI-Programmteil, die wichtigen 3 Forderungen erfüllt werden.
Man sieht auch sehr gut wie nun die Elemente des GUIs benutzt werden, ergo: IDECProgress ist ein Element des GUIs und gehört am besten direkt ins TForm statt in eigene Klasse die dann erst das GUI steuert (quasi doppelt gemoppelt).

Die Standardvorgehensweise beim IDECProgress in eigenen Klassen die DECs Objekte benutzten wäre also so das man den Parameter Progress: IDECProgress durchschleift bis zum GUI Programteil.


Gruß Hagen