C/C++ Socket State FIN_WAIT2 schließen

[7.e.Q]

Hi Leute,

neues Socket-Problem: unsere Software wird manchmal beendet und neu gestartet. Das Problem dabei ist, daß sie einen Socket aufmacht, der beim Beenden natürlich wieder geschlossen wird. Dieser Socket befindet sich nach dem Beenden im Zustand (netstat) FIN_WAIT2. shutdown(fd, 2); wird darauf schon aufgerufen, auch ein close(fd); erfolgt danach noch. Aber der Socket wird nicht komplett geschlossen. Wird die Software daraufhin unmittelbar neu gestartet, meldet bind, daß der Port schon belegt ist (Address already in use).

SO_REUSEADDR wollen wir nicht verwenden.

Wie bekommt man den eigentlich schon geschlossenen Socket aus dem Status FIN_WAIT2 heraus, also daß der Port komplett wieder freigegeben wird?

Danke
Gruß, Hendrik

[anda_skoa]

Vermutlich bedeutet der Zustand, daß der Kernel den Socket bzw damit verbundene Resourcen noch nicht wieder freigeben kann.

In deinem Fall ist es zwar ein UDP Socket, aber bei einem TCP Socket könnte zB noch auf das FIN/ACK der Gegenseite gewartet werden.

Ciao,
_

[7.e.Q]

Wodurch kommst du zu dem Schluss, daß es sich dabei um einen UDP Socket handelt? Dem ist nämlich nicht so. Es handelt sich tatsächlich um einen TCP Socket. Demnach erwartet der Socket dann das FIN/ACK der Gegenseite, wie du sagst. Verhindern lässt sich dies nicht, oder? Ursache ist also anscheinend die Gegenseite.

[anda_skoa]

Wodurch kommst du zu dem Schluss, daß es sich dabei um einen UDP Socket handelt?

Eine offensichtlich falsche Annahme beruhend auf deinen vorhergehenden Postings.


Verhindern lässt sich dies nicht, oder? Ursache ist also anscheinend die Gegenseite.

Dieser Handshake ist im Protokoll vorgesehen. Selbst wenn du die Verbindung schon neu benutzen könntest, wenn dieses Paket eintrifft, möchtest du vermutlich nicht, daß dann die neue Verbindung weg ist.

Ciao,
_

[7.e.Q]

Selbst wenn du die Verbindung schon neu benutzen könntest, wenn dieses Paket eintrifft, möchtest du vermutlich nicht, daß dann die neue Verbindung weg ist.

Ciao,
_

Korrekt. Kann dies passieren, wenn der Socket als Option das Reusable-Flag bekommt? Denn so ist es ja ohne weiteres möglich, den Port trotz eines im FIN_WAIT2 stehenden vorangehenden Ports wieder zu öffnen.

Welches Designkonzept sieht eine solche Situation vor? In diesem Fall handelt es sich um eine Software (die sogenannte Ladesoftware), die durch einen im gesamten Netzwerk einmaligen Dienst (sog. IWAN) auf einem System auf ein beliebiges anderes System geladen wird (dort läuft ein Loader-Programm). Der Loader startet die Ladesoftware, welche daraufhin einen TCP Server-Socket öffnet. Der Loader teilt dem IWAN dann mit, daß die Software gestartet wurde und der Port bereitsteht. Der IWAN baut daraufhin die Verbindung zum Loader ab und eine andere Verbindung zur Ladesoftware auf. Nun passiert es selbstverständlich im normalen Tagesgeschehen, daß diese Ladesoftware durch eine andere ersetzt werden soll, weil eine andere Funktionalität benötigt wird. Der Loader beendet die laufende Ladesoftware, welche natürlich auch brav alle Sockets schließt und so, und startet daraufhin die frisch geladene neue LadeSW. In diesem Moment tritt besagtes Problem auf. Der Socket, auf dem die LadeSW ihren Server aufmacht, ist noch geöffnet, steht im Zustand FIN_WAIT2. Das Problem haben wir durch das Reusable-Flag umgangen. Dies hat aber (meiner Meinung) manchmal sporadisch den Effekt, daß der IWAN trotz geöffnetem Port keine Verbindung zur LadeSW herstellen kann. Warum auch immer. Vermutlich erwischt er den falschen Port oder... keine Ahnung. Jedenfalls gilt es hier eben dafür zu sorgen, daß der Port bei Beendigung der LadeSW 100% geschlossen wird, daß Reusable also nicht erforderlich ist.

Ich kann mir gut vorstellen, daß das gesamte Konzept völlig falsch herum aufgezogen wurde. Man hätte viel mehr den IWAN als Server einrichten sollen. Stimmt, gebe ich zu. Allerdings ist eine Änderung dieses Systems mit einem enormen Aufwand verbunden, der zwar meiner Meinung nach sinnvoll und zweckdienlich ist, aber den leider keiner bezahlen will.

[anda_skoa]

Hmm, anstatt dem Reuse könnte die neue Ladesoftware einfach kurz warten und nochmal probieren den Socket normal zu öffnen.

Welche Strategie ist denn im Fall vorgesehen, daß jemand andere den Port belegt?

Ciao,
_

[7.e.Q]

War auf Seminar letzte Woche, daher schreib ich jetzt erst...

Die Ladesoftware könnte schon warten, bis der Port freigegeben wird und es dann nochmal versuchen, allerdings konnte ich beobachten, daß die Freigabe des Ports teilweise recht lange dauern kann (bis zu ein, zwei Minuten). Und das ist definitiv zu viel.

FIN_WAIT2 heißt doch, daß die Verbindung nur einseitig geschlossen wurde, seh ich das richtig? Dann muss also vermutlich die Gegenstelle fehlerhaft sein, wenn die Verbindung nach 'nem Close noch bestehen bleibt, korrekt?

[anda_skoa]

Bei guten Verbindung eine wahrscheinliche Sache.
Die Timeouts bei TCP sind relativ hoch, weil ja im allgemeinen nichts über alle Teilstücke der Verbindung gesagt werden kann.

Man kann zwar die Timeouts verändern, aber man sollte sich dann bewußt sein, daß man die Einsetzbarkeit auf genau passenden Umgebungen eingeschränkt hat

Ciao,
_