TClientSocket Socket wird nicht freigegeben

[Einhorn]

Hallo,

ich rechne mal damit, dass ich nicht der Erste mit diesem Problem bin. Allerdings habe ich offensichtlich nicht die richtigen Suchworte verwendet.

Prinzipiell mache ich etwas ganz einfaches: Mit einer TClientSocket Komponente (D5, ctNonBlocking) wird die Verbindung zu einem Server aufgebaut und nach der Kommunikation wieder abgebaut. Das ist notwendig, weil die Gegenseite nunmal nur mit einem Partner sprechen kann und dementsprechend wieder freigegeben werden muss.
Jetzt stellt sich für mich folgendes Problem dar:

Der Ablauf an sich funktioniert völlig reibungslos. Wenn ich allerdings die Windowskommandozeile aufrufe und mir mittels netstat die verwendeten Sockets anzeigen lasse, sehe ich, dass keine meiner Verbindungen wieder freigegeben wird. Langer Rede kurzer Sinn: Irgendwann habe ich auf den betreffenden Rechnern schlicht keine freien Ressourcen mehr. Beim Beenden des Programms sind wieder alle Sockets frei.

Welchen Trick übersehe ich?

Viele Grüße

Ingo

[Zacherl]

Hallo Ingo,

1) Erlaubt dir deine Serverseite vom Programmkonzept her keine Mehrfachverbindungen? Die Kapselung der WinSocks per TServerSocket erlaubt es dir nämlich definitiv mehrere eingehende Verbindungen anzunehmen und auch zu halten.

2) Wie beendest du denn die Socket Verbindung? Etwas Code wäre sicher hilfreich.

Viele Grüße
Zacherl

[mjustin]

Zitat von Einhorn:

Wenn ich allerdings die Windowskommandozeile aufrufe und mir mittels netstat die verwendeten Sockets anzeigen lasse, sehe ich, dass keine meiner Verbindungen wieder freigegeben wird.

In welchem Status sind die Sockets (TIME_WAIT, CLOSE_WAIT ...)?

Sockets bleiben eine gewissse Zeit nach dem Beenden der Verbindungen ncoh geöffnet durch das Betriebssystem.

Das SysInternals TCPView Tool ist noch ein wenig übersichtlicher als netstat, damit habe ich auch den Effekt nachvollzogen den man bei einer HTTP 1.0 Verbidung hat - die wird beiderseitig zwar geschlossen, ist aber immer noch eine Weile sichtbar (und dem "System" als Besitzer zugeordnet, nicht mehr der eigenen Anwendung). Das kann natürlich schnell zu Überlastungen führen.

[Zacherl]

Sollte es an CLOSE_WAIT liegen, hier noch ein hilfreicher Artikel:
http://blogs.technet.com/b/janelewis...lose-wait.aspx

[Einhorn]

Hi,

sorry.... die Codeschnipsel habe ich vergessen.

Prinzipiell relativ einfach:

Erzeugen des Clients:

DrClient := TClientSocket.Create(nil);
[..]
DrClient.Address := sDrucker_IP ;
DrClient.Port := iServer_Port;
DrClient.ClientType := ctNonBlocking;
[..]
// Lokale Proceduren zuordnen
DrClient.OnError := DrClientError ;
DrClient.OnConnect := DrClientConnect ;
DrClient.OnDisconnect := DrClientDisconnect ;
DrClient.OnRead := DrClientRead ;
DrClient.OnWrite := DrClientWrite ;
DrClient.OnConnecting := DrClientConnecting ;


[..]

Öffnen der Verbindung:

DrClient.Open;

Schließen der Verbindung:

DrClient.Close;





Die Verbindungen stehen im Status WARTEN bzw. WAIT

Hoffe, ich konnte mich verständlicher ausdrücken.

MFG

Ingo

[Einhorn]

Hi,

Zitat von Zacherl:

Hallo Ingo,

1) Erlaubt dir deine Serverseite vom Programmkonzept her keine Mehrfachverbindungen? Die Kapselung der WinSocks per TServerSocket erlaubt es dir nämlich definitiv mehrere eingehende Verbindungen anzunehmen und auch zu halten.

Die Serverseite stammt nicht von mir. Es handelt sich um eine Druckersteuerung eines Dritten auf die ich keinen Einfluss habe. Insofern bleibt mir nichts anderes übrig, als mich den Gegebenheiten anzupassen...

MFG

Ingo

[mjustin]

Zitat von Einhorn:

Schließen der Verbindung:

DrClient.Close;

Die Verbindungen stehen im Status WARTEN bzw. WAIT

Das ist normal - wenn der Client die Verbindung getrennt wird, bleibt der Socket noch eine Weile aktiv. Das ist aber erst bei über ca. hundert Verbindungen im TIME_WAIT Status ein potentielles Problem. (Je nach System auch ein paar mehr).

Wenn man die Verbindung zum Server wiederverwenden könnte - also das CLOSE erst wenn man keine weiteren Anfragen mehr senden / Daten vom Server erhalten will), reduziert sich das Problem. Das entspricht dem keep-alive in HTTP 1.1.