TIdTCPClient gibt nach Disconnect Socket nicht frei

[s.h.a.r.k]

hallo zusammen

ich habe gerade das folgende problem: und zwar nutze ich die indy-komponenten tidtcpserver und tidtcpclient, um einen datenaustausch zu implementieren. nun ist es so, dass ich beim onlclick auf einen button die verbindung vom client zum server aufbaue und dann nicht mehr disconnecte, bis ich wieder auf den button klicke oder das programm beendet wird. alleine hier tritt schon die frage auf, ob das irgendwas macht? weil ich schon gelesen habe, dass einigebei jeder anfrage erst connecten und dann sofort wieder disconnecten. find ich sehr seltsam :gruebel:

das eigentliche problem besteht beim disconnect: da wird der socket nicht freigegeben, obwohl ich eben dem client zum disconnect hinweise. sitze gerade nur am anderen rechner, aber ich meine, ich mache tcpclient.disconnect();, oder dergleichen. ich dachte das reicht an sich? aber selbst wenn ich die anwendung schließe ist der socket noch belegt, wie lange genau kann ich nicht sagen...

wieso wird der socket nicht freigegeben? selbst nach dem beenden des programms? bzw. was muss ich machen, dass der socket wieder freigegeben wird?! :wall:

mit freundlichen grüßen
der hai

[Klaus01]

Hallo,

wenn Du in einem cmd Box einmal netstat -nap ausführst
wirst Du sehen das der Zustand des Sockets/Ports nicht mehr ESTABLISHED ist.
Er wird im WAIT_TIME Status sein.
Das OS sorgt dafür das diese Sockets/Ports wieder entfernt werden.
Nach welcher Zeit das passiert - keine Ahnung.

Hier noch ein nettes Diagramm, dass die Stati einer TCP Verbindung aufzeigt.

Grüße
Klaus

[s.h.a.r.k]

ja genau, da steht dann wartend dran! das stimmt. ich schaue eben auch mit dem netstat-befehl auch nach, welche verbindungen "online" (im weitesten sinne) onlnie sind.

wie komme ich aber um diesen "fehler" drum herum, denn wenn man nun die anwendung zwei mal mit dem gleichen port ausführt, dann klappt es das zweite mal nun mal nicht mehr und das ist nicht wirklich toll! was ich auch schon gemacht habe ist die portnummer weggelassen. dann ist es halt so, dass er sich eine passende frei nummer sucht, aber ich mag es einfach definiert haben, sodass ich dies auch in der dokumentation nieder schreiben kann.

ich hoffe, dass es doch einen passende lösung dafür gibt!?

[Klaus01]

hier wird geschrieben ( am Ende der Seite), das man den Socket mit so_reuse erstellen kann
um ihn anschließend gleich wieder zu verwenden.

Aber mal eine Frage, was zwingt Dich denn dazu die ClientSeite immer auf einen festen Port zu binden?

Grüße
Klaus

[s.h.a.r.k]

da magst du echt recht habe. kommt nur drauf an, was das alles für konsequenzen hat. die software läuft in einem unternehmens-netzwerk und ich gehe einfach davon aus, dass es für eine dokumentation besser ist, dass der port, auf dem eine anwendung läuft, fest dokumentiert ist. ich finde, dass es sich ein wenig "wischi-waschi" anhört, wenn ich sage, dass sich der port selbst einstellt, wobei das eben mehr flexibilität schafft.

an dieser stelle wäre es allerdings interessant zu wissen, wie sich der port dann "selbst" einstellt, bzw. wie ein freier port ermittelt wird!?

[Klaus01]

nun, der Server läuft auf einem definierten Port.
Den siehst Du mit netstat -a im Status LISTENING.
Dieser Port wird auch direkt wieder freigemacht sobald der Serverdienst beendet wurde.

Der Client sendet nun zu diesen ServerPort ein SYNC.
Der Port von dem der Client sendet ist mehr oder weniger beliebig.
Der Server antwortet nun mit einem Sync-Ack auf diesen Port, der Sever weiß von welchem
Port der Client gesendet hat, denn er hat ja das SYNC Packet empfangen.

Sollte eine Firewall im Kommunikationsweg sein, so muss diese von ausserhalb
auf dem definierten Serverport durchlässig sein. Wenn Ports von der Innenseite
angefragt werden, so werden diese in der Regel durchgelassen.

Delphi-Quellcode:

   angennommen der Server lauscht auf Port 50000
   aussen                  FW                     innen
   Client    ->SYNC,50000  FW  ->  SYNC,50000   ->  Server
   Client    <-SYNC,ACK    FW  <-  SYNC,ACK    <-  Server

Grüße
Klaus

[s.h.a.r.k]

ah, vielen dank ;) trägt echt sehr zu meinem verständnis bei. jetzt hat sich wohl einiges erübrigt ;)