Fehler mit Socket komponente

[1aa]

auf meinem Testsystem nach ca 20 - 25 min

[Zacherl]

Ohne jetzt ein konkretes Problem zu sehen: Du musst das Socket nicht vor jedem Connect neu erstellen. Es reicht vollkommen aus, wenn der der alten Instanz sagst, dass sie erneut versuchen soll eine Verbindung herzustellen.

Das weiteren würde ich mit blocking Sockets innerhalb eines Thread arbeiten. In diesem Falle bekommst du einen Disconnect unmittelbar mit, wenn der blocking Call dann failt und kannst direkt versuchen die Verbindung erneut herzustellen.

Mit non blocking Sockets kann es dir sogar passieren, dass dein Timer die ".Open" Methode mehrfach während eines schon laufenden Verbindungsaufbaus aufruft (wenn der Verbindungsaufbau länger als 1 Sekunde dauert).

[1aa]

ok das mit dem blocking Sockets werde ich noch mal testen....

Das mit dem neu erstellen vor jedem connect hat ich nur zu Testzwecken ausprobiert ob das was ändert.... hat es aber nicht^^ :?

Ich hatte heute etwas zeit zum Testen wann die Fehlermeldung kommt hängt vom jeweiligem System ab.... auf meinem Netbook kommt sie nach ca. 20-25min auf meinem Hauptrechner erst nach ca. 5-6 h

Muss wahrscheinlich an der Socket Verarbeitung von Win liegen...das mit jedem Connect versuch der Fehlschlägt mehr Arbeitsspeicher belegt und nicht wieder freigegeben wird...

Ach ja und auf die Frage mit den Handles: Start ist bei 82 und je connect Versuch wird die zahl um 2 erhöht...sobald eine Verbindung aufgebaut wurde bleibt die Zahl konstant wenn die verbindung wieder abbricht läuft der zähler wieder weiter... :x

[Zacherl]

Kannst du das Programm auf deinem Laptop mal im Debugger testen und wenn der Fehler auftritt, anschauen welcher (WinAPI) Funktionsaufruf dazu führt? Eventuell ist die ScktComp Implementation in deiner Delphi Version fehlerhaft und leaked tatsächlich Handles. Ich teste das Verhalten gleich mal bei mir.

Edit: Kann das Verhalten bezüglich der Handles auch für XE4 unter Win8 bestätigen. Es werden bei jedem erfolglosen Verbindungsversuch 2 Handles geleaked.
Edit: Bei blocking Sockets funktioniert alles normal. Ich kann nur spekulieren, aber ich vermute mal, dass bei den asynchronen Sockets irgendwelche Handles zwecks Error Reporting oä. geöffnet bleiben. Wenn du mal versuchst in einer Schleife z.b. 100x zu einem nicht verfügbaren Host zu connecten, wirst du feststellen, dass sämtliche Fehlermeldungen erst nach Ablauf der Schleife angezeigt werden. Irgendwo muss die Komponente oder das System ja vermerken, dass noch eine Fehlermeldung ausstehen. Das dürfte das Memory Leak erklären.

[1aa]

Spitze Danke für deine Hilfe jetzt funkt es

:-D:thumb:

[Union]

Wie hast Du es jetzt konkret gelöst? Bei meinen Tests mit WinXP und Delphi 7 stieg die Anzahl der Handles nämlich nur bei erneutem Erzeugen der TClient-Klasse aber nicht nach den Verbdindungsversuchen.

[Zacherl]

Zitat:

Zitat von Union (Beitrag 1224803)

Wie hast Du es jetzt konkret gelöst? Bei meinen Tests mit WinXP und Delphi 7 stieg die Anzahl der Handles nämlich nur bei erneutem Erzeugen der TClient-Klasse aber nicht nach den Verbdindungsversuchen.

Ich vermute mal, er verwendet jetzt die blocking Sockets. Vielleicht handelt es sich um einen Fehler in der RTL implementation der TClientSocket Klasse, der sich erst in späteren Delphi Versionen eingeschlichen hat. Ich habe in meiner Testanwendung die Socket Instanz nicht neu erstellt und dennoch wurden die Handles geleaked. Nichtmal nach dem abschließenden Freigeben der Komponente wurden die Handles wieder geschlossen.

[Union]

Es gibt nur wenige Änderungen zwischen D7 und XE4 in den ScktComp, bis auf die allfälligen Unicode-Umstellungen und Namespaces:

• Es gibt ein overload von Close. Vielleicht sollte man in diesem Fall dann diesen verwenden, obwohl davor gewarnt wird. Der sorgt nämlich für das "Search und Destroy" des Handles.
• Bei ReceiveBuf wird jetzt die Count-Var erhöht falls der Puffer inzwischen mehr Daten enthält als vermutet bzw. übergeben.
• Im Accept werden EAbort-Exceptions stummgeschaltet

[1aa]

Ich verwende jetzt blocking Sockets und es funkt. soweit auch alles, keine Memory Leak :-D

Aber eine andere Sache ist mir jetzt auf gefallen seit ich blocking Sockets verwende habe ich probleme dateien zu übertragen :


Empfang:

Delphi-Quellcode:

procedure TClient.DateiDownload(Socket: TCustomWinSocket);
var zielDatei: TFileStream;
    nSocketStream : TWinSocketStream;
    nReceived: Integer;
    Buffer: array [0..9999] of Char;
begin
 zielDatei := TFileStream.Create('neu.txt', fmCreate);
 try
   bDateiEmpfang := True;
   nSocketStream := TWinSocketStream.Create(Socket,5000);
   try
    while bDateiEmpfang do
     begin
         nReceived := nSocketStream.Read(Buffer, sizeof(Buffer));
         if nReceived <= 0
           then Break
           else
             zielDatei.WriteBuffer(Buffer, nReceived);
       Sleep(1);
     end;
   finally
     nSocketStream.Free;
   end;  
  zielDatei.Position := 0;
  bDateiEmpfang := false;
 finally
   zielDatei.Free;
 end;
end;

Es scheint nicht alle daten zu übertragen.....

Senden:

Delphi-Quellcode:

Socket.SendStream(TFileStream.Create('neu.txt', fmOpenRead or fmShareDenyWrite))

[1aa]

Edit : OK hat sich geklärt hatte in einer übergeordnenen Procedure einen Tip fehler... Funktioniert alles

Danke noch mal an alle die mir geholfen haben!