Problem mit Dateigröße per FileStream-Übertragung

[Helmi]

Hallo,

ich hab ein kleines Problem:
ich habe zwei Programme - eines mit ServerSocket (Server), das andere mit ClientSocket (Client)

Der Server sendet an den Client eine Datei.
Code Server:

Delphi-Quellcode:

      try
        //Datei senden
        Serversocket.Socket.Connections[ausgewaehlter_Client].SendStream(
        TFileStream.Create(Edit_Quelle_Datei.Text, fmOpenRead or fmShareDenyWrite));
      finally
        // leer
      end;

Code Client:

Delphi-Quellcode:

           //Zieldatei erzeugen
           ZielDatei := TFileStream.Create(SaveFile, fmCreate);

           //Variablen beschreiben
           ProgressBar_Update.Position := 0;
           pbReceived := fSize;

           //Datei empfangen und speichern
           while True do
            begin
              nReceived := Socket.ReceiveBuf(Buffer, sizeof(Buffer));
              If nReceived <= 0 then
                Break
              else
                ZielDatei.WriteBuffer(Buffer, nReceived);

              delay(300);

              pbReceived := pbReceived - nReceived;
              ProgressBar_Update.Position := 100 - ((pbReceived * 100) div fSize);

              Application.ProcessMessages;
            end;
          finally
            //Variablen leeren
            ZielDatei.Position := 0;
            Buffer := '';

            //ZielDatei freigeben und löschen
            FreeAndNil(ZielDatei);

Der Server übermittelt aber, bevor die Datei übertragen wird, die Größe der zu übertragenden Datei.

Nachdem der Client die Datei empfangen hat, prüft dieser ob 1. die Datei vorhanden ist und 2. ob die Größe der empfangenen Datei gleich der Größe ist, die zuvor übermittelt wurde.

Und da hab ich ein Problem. Es kann sein, dass die Größen nicht übereinstimmen.


Hat jemand ne Ahnung was es sein könnte, dass die Größen nicht übereinstimmen?
Kann es sein, dass es durch das Senden mit dem Stream zu Veränderung der Dateigröße kommen kann?

[marabu]

Du solltest dir vielleicht folgende Fragen beantworten:

• Wie groß ist die Abweichung?
• Ist die Abweichung immer gleich?
• Welche Dateitypen sind betroffen?
• An welchen Stellen unterscheiden sich die gesendete und die empfangene Datei laut comp/filecomp/diff?

Das sollte dir einige Hinweise geben.

[yankee]

Das kann zum Beispiel am Dateisystem liegen. Jenachdem, ob du FAT oder NTFS benutzt könenn geringfügigige Unterschiede auftreten. Um sicherzustellen, dass eine Datei wirklich vollständig ist, würde ich ine md5-checksum nehmen:
http://www.torry.net/quicksearchd.ph...=md5&Title=Yes

[Muetze1]

Moin!

Es liegt einzig und alleine daran, zu erkennen, dass das OnClientRead() Ereignis mehrfach aufgerufen wird, bevor alles empfangen wurde. Es ist immer wieder das gleiche, das alle davon ausgehen, das ein OnClientRead immer auch gleich alle Daten bereit hält. Dem ist nicht so. Das OnClientRead wird immer ausgelöst, sobald er Daten empfangen hat - und wenn es nur ein Teil ist. Genauso wenig kann man davon ausgehen, das ReceiveText() die mit SendText() gesendeten Texte genauso gesplittet und als ganzen empfängt.

/EDIT: "zu erkennen" - nicht im programmiertechnischen Sinne, sondern im Sinne des Verständnisses bei dem Programmierer.

MfG
Muetze1

[Helmi]

Hallo,

Zitat von marabu:

• Wie groß ist die Abweichung?
• Ist die Abweichung immer gleich?
  

Ich hab mir die Dateigröße mal anzeigen lassen: Interessant ist es, dass manchmal die Dateigröße "-1" - also eigentlich nicht vorhanden ist.

Zitat von marabu:

• Welche Dateitypen sind betroffen?
  

Da ich nur Exe-Dateien schicke, kann ich nur von Exe-Dateien reden.

Zitat von marabu:

• An welchen Stellen unterscheiden sich die gesendete und die empfangene Datei laut comp/filecomp/diff?
  

Was meinst du damit?

Zitat von yankee:

Das kann zum Beispiel am Dateisystem liegen. Jenachdem, ob du FAT oder NTFS benutzt könenn geringfügigige Unterschiede auftreten

Ich hab die Probleme auch von NTFS zu NTFS.
Von NFTS zu FAT32 hab ich die wenigsten Probleme.

Zitat von Muetze1:

s liegt einzig und alleine daran, zu erkennen, dass das OnClientRead() Ereignis mehrfach aufgerufen wird, bevor alles empfangen wurde. Es ist immer wieder das gleiche, das alle davon ausgehen, das ein OnClientRead immer auch gleich alle Daten bereit hält. Dem ist nicht so. Das OnClientRead wird immer ausgelöst, sobald er Daten empfangen hat - und wenn es nur ein Teil ist. Genauso wenig kann man davon ausgehen, das ReceiveText() die mit SendText() gesendeten Texte genauso gesplittet und als ganzen empfängt.

Bevor der Client aus dem Stream liest (klingt blöd - ich weiss), wird eine Variable auf "true" gesetzt, die ein mehrmaliges Starten der Auslesens verhindert. Erst wenn alles vorbei ist, wird diese Varialbe wieder auf "false" gesetzt.


Ich hab jetzt mal ein "Delay(1000)" beim Server reinprogrammiert, bevor dieser den Stream sendet - daraufhin hat sich das ganze deutlich verbessert und es funktioniert bei jedem mal. Ich weiss jetzt nicht ob das so ganz der Stein der Weisen ist.
Aber ich werd das jetzt mal etwas im Auge behalten.

[Muetze1]

Moin!

Wozu gibt es Ereignisse die eine Event-Driven Programmierung ermöglichen sollen, damit die Anwendung nicht hängt und bedienbar bleibt, wenn du alles über den Haufen schmeisst und eine Polling Schleife baust die entgegen allen Regeln und normalen Nutzungen spricht. Wozu nutzt du überhaupt den Event? Wozu? Dann kannste auch in einen ButtonClick die Schleife reinsetzen.

Deine Lösung ist so, als wenn auf der Post wohnen würdest, weil du irgendwann ein Packet bekommen würdest. Dazu lebst du vielleicht eine Woche auf der Poststelle, damit du sofort dein Packet bekommst, wenn es ankommt (polling). Im Normalfall, wirst du aber durch eine Karte vom PostBoten benachrichtigt, dass ein neues Packet angekommen ist (event-driven).

Mach wie du willst, du hast ja eine Lösung - aber ich verstehe es einfach nicht...

MfG
Muetze1

[Helmi]

Hallo,

ja ich weiss - da ist noch ein kleiner Fehler drin - ich bin auch am überlegen dass ich zuerst eine "Benachrichtigungs-Karte" schicken werde, bevor ich das Paket abholen kann.

Deutsche Post - wir danken Dir

Aber Muetze hat schon recht - so richtig sauber ist das nicht was ich gemacht hab - ich werd es noch umprogrammieren.