TIdHTTPWebBrokerBridge und die Connections (TIME_WAIT)

[moelski]

Moin !

Ich nutze den TIdHTTPWebBrokerBridge um einen Webservice bereit zu stellen. Funzt soweit auch. Was aber schon merkwürdig ist sind die Connections die TIdHTTPWebBrokerBridge offen hält.

Ich nutze dazu das proggy TCPView (Sysinternals) um das zu monitoren. Wenn sich nun ein Client mit dem Webservice unterhält, dann steht danach eine solche Verbindung im TCPView:

Code:

[System Process]:0   TCP   <RECHNER>:6060   <RECHNER>:1288   TIME_WAIT

Nach ca. 2 Minuten verschwindet die Connection dann.

Müsste die nicht im Normalfall sofort verschwinden? Der Client macht einen Connect zum TCP Server, kommuniziert und macht ein disconnect. Oder sehe ich da was falsch?

Auch mit NetStat -an kann man sich das ansehen:

Code:

TCP    <IP>:1297    <IP>:22222      WARTEND

Das blöde an der Sache ist nun, das - wenn der Webservice schnell abgefragt wird - eine Menge Connections rumdümpeln und auf ihr Timeout warten.

Hat jemand eine Idee?

[Assertor]

Hallo moelski,

Zitat:

Zitat von moelski

Was aber schon merkwürdig ist sind die Connections die TIdHTTPWebBrokerBridge offen hält.

Ich ändere das mal: die Connections die Windows offen hält.

TIME_WAIT und 2 Minuten sind das deutliche Indiz.

Zitat:

Zitat von moelski

Müsste die nicht im Normalfall sofort verschwinden? [...] Oder sehe ich da was falsch?

1) Nein und 2) Ja.

Nach der Socket Freigabe wartet der TCP/IP Stack per Default 120 Sekunden für die Freigabe aus dem FD_WAIT State. Dieses Verhalten des Betriebssystems soll u.a. einer sauberen Beendigung der Kommunikation dienen.

Zitat:

Zitat von moelski

Das blöde an der Sache ist nun, das - wenn der Webservice schnell abgefragt wird - eine Menge Connections rumdümpeln und auf ihr Timeout warten.

Hat jemand eine Idee?

Ja, das ist richtig. Deswegen kann man dieses Verhalten über die Registry (insb. bei Servern) steuern. Grundlagen hier: http://msdn.microsoft.com/en-us/library/ms819739.aspx und guter Suchbegriff ist "TcpTimedWaitDelay".

Schau auch mal, ob bei der WebBrokerBridge sowas wie ReuseSocket als Property verfügbar ist (ich weiß das jetzt nicht aus dem Kopf).

Wenn Du am Zielrechner das Verhalten änderst, mußt Du aber mit den freien Ports aufpassen. Gerade bei W2k3 oder W2k8 sind dort iirc nur Ports 1000 bis 5000 für ausgehende Kommunikation frei, da kommt man schnell als Limit.

hth,

Gruß,
Assertor

[moelski]

Moin !

Danke für die Infos.

Zitat:

ReuseSocket

Das habe ich schon mal getestet:

Delphi-Quellcode:

FWebBrokerBridge.ReuseSocket := rsTrue;

Hatte aber leider keinen Einfluss. Wobei ich nur rsTrue getestet habe.
Generell wäre ja folgendes möglich:

Delphi-Quellcode:

TIdReuseSocket = (rsOSDependent, rsTrue, rsFalse);

[Assertor]

Moin :)

Zitat:

Zitat von moelski

Moin !

Danke für die Infos.

Klar, gerne.

Zitat:

Zitat von moelski

Zitat:

ReuseSocket

Das habe ich schon mal getestet:

Delphi-Quellcode:

FWebBrokerBridge.ReuseSocket := rsTrue;

Hatte aber leider keinen Einfluss. Wobei ich nur rsTrue getestet habe.
Generell wäre ja folgendes möglich:

Delphi-Quellcode:

TIdReuseSocket = (rsOSDependent, rsTrue, rsFalse);

Ja, das hatte ich mir schon gedacht. Für das System sind es unterschiedliche Verbindungen (selbst bei gleicher IP sind es andere Destination Ports), da kann das leider nicht helfen. Also bleibt nur der Umweg über das OS Timeout.

Gruß,
Assertor