Protokollentwicklung

[wedmer]

Hm, wie esch scheint, haben wir wieder einmal das selbe Problem. Anfangs lief bei mir das Progi, also dass heisst einmal, und jetzt habe ich auch diesen Fehler, allerdings nicht immer bei der selben Adresse. Auch wenn ich das delete auskommentiere, tritt dieser Fehler manchmal auf.

[junix]

Man sollte ja auch die mit "new" erstellen Instanzen von Objekten prüfen ob sie denn wirklich erstellt wurden bevor man sie benutzt (o;

-junix

[net 0]

ich bin zwar nicht so der borland-freak aber so'n tcp-stack arbeitet immer asynchron. wenn man dem den buffer unterm hintern weglöscht kann's schon crashen. diese borland-klassen haben doch sicher 'ne möglichkeit den status des sockets abzufragen bzw. ob der noch am senden ist etc. erst wenn alles wech ist sollte man die buffer löschen, die datei schliessen usw.

[Zero01]

Eigentümer des Stream, der als Parameter an SendStream übergeben wird, wird das Windows-Socket-Objekt. Das Windows-Socket-Objekt gibt den Stream nach erfolgter Verarbeitung frei. Versuchen Sie nicht, den Stream, nachdem er als Parameter übergeben wurde, freizugeben.

So, jetzt bekomm ich keine Access Violation mehr beim Senden. Jedoch wird die Datei beim erstellen immer zu groß

Senden

mem = new TMemoryStream();
   mem->LoadFromFile(Form1->OpenDialog1->FileName);
   mem->Seek(0,0);

   if (mem)
   Form1->ClientSocket1->Socket->SendStream(mem);

Empfangen

int Buffer = 1024;
  int filesize = StrToInt(FileSize(filelist->Values[Socket->RemoteAddress]));
  String filename = FileName(filelist->Values[Socket->RemoteAddress]);

  BYTE *Buffer_BYTEp = new BYTE[Buffer];
  Stream->Position = Stream->Size;

  Socket->ReceiveBuf(Buffer_BYTEp, Buffer);
  Stream->Write(Buffer_BYTEp, Buffer);

  delete [] Buffer_BYTEp;

  if (Stream->Size >= filesize)
  Stream->SaveToFile(Form2->Label1->Caption + "\\" + filename);

Wenn das OnReceive Ereignis einmal ausgelöst wird ist die Datei 1024byte groß und beim zweiten mal 2048.......... Die Quelldatei war aber 1147 bytes groß

Wie hast du das empfangen gelöst ?

[junix]

Was willst du denn mit dem "if (mem)" da noch?

Ausserdem würde ich nochmal genau überlegen, ob ReceiveBuf() wirklich immer die ganze Buffersize empfängt oder nicht. Als kleiner Tip: Es muss einen Grund geben, wieso ReceiveBuf() das zurückliefert was es zurückliefert (o;

Ansonsten ist das Verhalten aber völlig logisch... Denk nochmal genau darüber nach.

-junix

[Zero01]

Jaaaaa Junix mein Freund, pro Aufruf subtrahiere ich 1024 byte von filesize solange bis nur noch ein Rest kleiner 1024 bleibt und dies die letzte Puffergröße ist

<= Held vom Erdbeerfeld

[junix]

Heisst das jetzt, dein Problem ist gelöst?

Übrigens: Ich persönlich fänds erheblich eleganter den Rückgabewert von ReceiveBuf() auszuwerten. Es verringert die Dateifehler (o;

-junix

[edit]Ausserdem kümmer dich mal um ordentliche Kommentare und wichtiger: Anständige und aussagekräftige Variablennamen!!![/edit]

[Zero01]

Das habe ich schon gemacht. Muss zum Fliegerarzt und melde mich später wieder !

[wedmer]

Ich habe das senden und empfangen so weit hin gekriegt. Zuerst kommuniziert der Client etwas mit dem Server, es wird mitgeteilt, ob Daten gesendent werden sollen, dann die Grösse der Datei und wenn der User dies empfangen möchte, wird dann der Stream gesendet. Ich habe zusätzlich noch ein Form angelegt, welches den Status der Übermittlung anzeiget, Totale Anzahl zusendender Bytes, Anzahl der gesendeten Bytes und einem TCGauge als Frotschrittsanzeige. Das Problem ist jetzt, dass ich ja ein

Application->ProcessMessages();

benötige, um das Label mit den empfangenen Bytes zu aktualisieren. Blos wenn ich das drin habe, erhalte die Fehlermeldung: Zugriffsverletzung bei Adresse blablabla. Lesen von Adresse blablabla. lass ich es weg geht alles gut. Wieso?
Hier mal der Code:

BytesReceive = Socket->ReceiveBuf(Buffer, BufferSize); //Buffer auslesen
      Stream->Write(Buffer, BytesReceive);                      //Buffer in Stream schreiben
      TotalBytesReceived += BytesReceive;                       //Anzahl empfangene Bytes aufsummieren
      Progress->TransferStatus->Progress = TotalBytesReceived;
      Progress->SendBytesLabel->Caption = TotalBytesReceived;
      //Application->ProcessMessages();
      if(TotalBytesReceived == TotalBytes)
      {
         free(Buffer);                                   //Speicherbereich wieder frei geben
         Progress->Close();                              //Statusfenster schliessen
         Stream->Seek(0, soFromBeginning);               //Stream auf Anfang setzten
         Stream->SaveToFile(SaveDialog1->FileName);      //Stream abspeichern
         Stream -> Clear();                              //Speicher freigeben
         delete Stream;                                  //Stream frei geben
         delete [] Buffer;                               //Buffer frei geben
         FileReadyToReceive = false;
         FileSizeReadyToReceive = false;
         FileSizeReceive = false;
         ServerSocket1->Close();
      }

[Zero01]

Hab deine Variante in ne Testversion eingebaut und muss feststellen das der MemoryStream beim senden sowas von lahm ist. Wird der Stream byte für byte versendet :p ?
ProcessMessages verwendet man in Schleifen, wie es bei events aussieht weiß ich leider noch nicht. Komisch ist das der Empfänger abraucht wenn ich das 2. mal senden möchte. Der erste File Transfer klappt super aber lahm. Bisher hat der Filestream am besten Funktioniert auch wenn er mir 80 -100 % CPU Last für den Process beansprucht.

@wedmer: Ich kann ab Sonntag Abend wieder Mitarbeiten wenn ich vom Flugplatz zurück bin. Das bekommen wir schon hin

@Junix: Vielen Dank für deine unermüdliche Hilfe, ich bereite das OnReceive auf und Poste es am Sonntag

[junix]

wedmer schrieb:

[...]
         free(Buffer);                                   //Speicherbereich wieder frei geben
[...]
         delete [] Buffer;                               //Buffer frei geben
      }

Was soll das denn werden?

Wenn new [] dann ist free bestimmt nicht gefragt.

Kleiner Tip am Rande. Wenn delete ausgeführt wird, dem Zeiger gleich NULL zuweisen. Das führt dazu, das man doppelte Löschungen besser findet (AV auf Adresse 0 ist eindeutiger zu identifizieren.)

[wedmer]

Ups,
dass free(Buffer) kam daher, dass ich zuerst den Buffer mit malloc erstellt habe und als ich dann auf new gewechselt habe. Habe jetzt nach jedem delete ein =NULL eigesetzt. Jetzt erhalte ich aber immer noch eine Information, mit dem Inhalt Zugriffsverletzung auf eine Adresse ≠0x00000000 liegt das daran, dass Application->ProcessMessages(); nicht bei Events verwendet werden darf, da es ja eigentlich für Schleifen gedacht ist?

@Zero01: habe nun meine MemoryStreams in FileStreams umgewandelt, kann bei mir aber bei der Geschwindigkeit keine Unterschied feststellen.

[junix]

Hat damit gar nichts zu tun. Wo genau passiert denn die AccessVoilation?

Jedenfalls ist das alles jetzt ein Indiz dafür, dass du irgendwo Speicher zerstörst, auf den du in einem späteren Event wieder zugreifen würdest.

[wedmer]

Wo genau weiss ich auch nicht, er zeigt mir im CPU-Fenster auf den Befehl:
7C91EDDC push ebx
Wo dies im Code genau ist, weiss ich auch nicht. Es muss von mir aus gesehen im OnClientRead-Event sein die Meldung tritt erst ein, nach dem bereits einig Bytes Übertragen wurden.
komisch ist, dass die Meldung nur kommt, wenn ich die ProcessMessages() drin lasse, nehme ich die raus geht alles prima.

[junix]

Scroll mal im CPU-Fenster hoch bis zur nächsten dir bekannten Zeile in C. Alternativ schliesse das CPU-Fenster und du solltest in der IDE die passende Zeile markiert kriegen.

Wenn das auch nichts hilft, dann findest du irgendwo in den Debugfenstern (Ich gluab View-> Debug) den sogenannten "Callstack" oder "Aufrufstack" da wird dir angezeigt in welcher Funktion du grade steckst und wie du da hingelangt bist (aufrufende Funktionen)

[wedmer]

junix schrieb:

Scroll mal im CPU-Fenster hoch bis zur nächsten dir bekannten Zeile in C.

Wie meinst du das? Bei mir stehen im CPU-Fenster nur Assembler befehle.
Habe jetzt mal das mit dem Aufruf-Stack gemacht, da steht bei mir: ntdll.dll

[WebFritzi]

Es kann doch sein, dass die VCL intern mit WSAAsyncSelect() arbeitet. Dann wird beim Eintreffen von Daten eine Message an die Form gesendet. D.h., er geht wieder in OnReceive rein. Eine feine Rekursion, die möglicherweise den Fehler verursacht...
So kannst du einfach prüfen, ob meine Vermutung tatsächlich der Fall ist:

void __fastcall TForm1::OnReceiveData(TObject* Sender)  // Oder was weiß ich, wie die Rotine bei dir heißt...
{
   static bool IsProcessMessagesOn = false;

   if( !IsProcessMessagesOn )
   {
      BytesReceive = Socket->ReceiveBuf(Buffer, BufferSize); //Buffer auslesen 
      Stream->Write(Buffer, BytesReceive);                      //Buffer in Stream schreiben 
      TotalBytesReceived += BytesReceive;                       //Anzahl empfangene Bytes aufsummieren 
      Progress->TransferStatus->Progress = TotalBytesReceived; 
      Progress->SendBytesLabel->Caption = TotalBytesReceived; 

      IsProcessMessagesOn = true;
      Application->ProcessMessages(); 
      IsProcessMessagesOn = false;

      if(TotalBytesReceived == TotalBytes) 
      { 
         free(Buffer);                                   //Speicherbereich wieder frei geben 
         Progress->Close();                              //Statusfenster schliessen 
         Stream->Seek(0, soFromBeginning);               //Stream auf Anfang setzten 
         Stream->SaveToFile(SaveDialog1->FileName);      //Stream abspeichern 
         Stream -> Clear();                              //Speicher freigeben 
         delete Stream;                                  //Stream frei geben 
         delete [] Buffer;                               //Buffer frei geben 
         FileReadyToReceive = false; 
         FileSizeReadyToReceive = false; 
         FileSizeReceive = false; 
         ServerSocket1->Close(); 
      }
   }
}

So könnte es zwar sein, dass nicht alles durchkommt, aber du wirst merken, ob du wieder eine AccessViolation bekommst oder nicht. Ich würde dir eh dazu raten, die ganze daten-Empfangs-Routine in einen eigenen Thread zu packen.

[wedmer]

Super Tip danke, genau da lag der Fehler. Dann werde ich einfach die Anzeige der empfangenen Bytes weglassen, das TCGauge genügt ja auch.

[Zero01]

Bei mir funzt es mittlerweile auch schon gut, Perfekt ist es aber noch nicht da Teilweiße die Sendeschleife rausspringt obwohl der File noch gar nicht zu ende gesendet wurde:

char buf[1024];
 int c,b;

 TFileStream *in = new TFileStream(Form1->OpenDialog1->FileName, fmOpenRead);
 in->Seek(0,soFromBeginning);

do
     {
         Application->ProcessMessages();
         b = in->Read(buf,sizeof(buf));
         c = Form1->ClientSocket1->Socket->SendBuf(buf,b);

        while(c == -1)
        {
         Application->ProcessMessages();
         b = in->Read(buf,sizeof(buf));
         c = Form1->ClientSocket1->Socket->SendBuf(buf,b);
        }
    }
     while(b == sizeof(buf));
     delete in;

Was mache ich falsch da er manchmal zu früh aufhört zu senden? Beispiel: Von 123456 bytes sendet er dann meistens nur 123453. Wie schaffe ich es das er immer die komplette Datei überträgt ?

[Zero01]

So, nun hab ich ne einigermaßen stabile Variante ausgetüftelt:

char buf[1024];
 int c,b,bytecount = 0;

     TFileStream *in = new TFileStream(Form1->OpenDialog1->FileName, fmOpenRead);
     in->Seek(0,soFromBeginning);

      do
     {
         Application->ProcessMessages();
         b = in->Read(buf,sizeof(buf));
         c = Form1->ClientSocket1->Socket->SendBuf(buf,b);

           if (c != -1)
           {
            UploadWindow->ProgressBar1->Position += c;
            bytecount += c;
            UploadWindow->Label7->Caption = String(UploadWindow->ProgressBar1->Position)+ " bytes";
           }
        while(c == -1)
        {
         c = Form1->ClientSocket1->Socket->SendBuf(buf,b);

               if (c != -1)
             {
              UploadWindow->ProgressBar1->Position += c;
              bytecount += c;
              UploadWindow->Label7->Caption = String(bytecount)+ " bytes";
             }
        }
    }
     while(File_Size > bytecount && b == sizeof(buf));
     delete in;

Sieht jemand von euch Fehler mehrere Files sendet er problemlos aber bei einigen Bricht er ziemlich am Ende des Files die do-while Schleife ab