UDP Port bleibt nach Programmende in Benutzung

[jaenicke]

Hallo zusammen,

wir haben hier ein seltsames Phänomen. Wir haben es mit Indy und ICS ausprobiert, es ist bei beiden Frameworks das gleiche Resultat.

Wir benutzen einen UDP Server um dort Pakete hinzuschicken. Wenn das Programm aber beendet wird, bleibt der Port geöffnet. Laut Process Explorer und netstat in "System", nicht mehr in der (ja auch schon geschlossenen) Anwendung.

Beim nächsten Start der Anwendung kann der Port nun nicht mehr benutzt werden, klar. Komisch ist, dass es beim zweiten Start dann aber in der Regel geht. Danach ist der Port nämlich plötzlich nicht mehr vom System in Benutzung.

Eine offene VPN Verbindung scheint das Problem zu begünstigen, es ist aber auch schon ohne aufgetreten.

Hat dieses Phänomen schon einmal jemand gehabt? Hat jemand Ideen, vielleicht sogar eine Lösung?

Vielen Dank,
schönen Gruß,
Sebastian

[Captnemo]

Schon mal probiert, den Port im Programm zu schließen und wieder zu öffnen? Und was sagt Netstat, wann du den Port im Programm nur schließt (also nicht mit Programmende)?

Wird bei Programmende der Port richtig geschlossen (auch erfolgreich geschlossen) und alles aufgeräumt?

Wie sieht die Prozedure zum Öffnen des Ports aus, bzw. was machst du wenn der Port nicht geöffnet werden kann?

[jaenicke]

Eigentlich sieht alles gut aus, wenn man das so simuliert.

Aber:

• Wenn die VPN Verbindung verloren geht während der Port reserviert ist, kann er nicht mehr freigegeben werden
• Wenn die Anwendung z.B. per Taskmanager abgeschossen wird oder ein Fehler auftritt, so dass die Deinitialisierung nicht durchlaufen wird, räumt Windows den Port nicht auf
• Wenn der Port unter deutlicher Last liegt und in dem Moment der Freigabe Datenpakete ankommen, wird er nicht aufgeräumt trotz Freigabe durch die Anwendung

Ich halte das für einen Fehler in Windows. Wie ich das lösen soll habe ich aktuell keine Ahnung.

// EDIT:
Erneute Versuche nach kurzer Verzögerung den Port erneut zu aktivieren schlagen ebenfalls fehl.

// EDIT2:
Längere Verzögerung scheint zu gehen (20 Sekunden). Aber das Problem scheint auch weg zu sein, wenn ich als Broadcastadresse nicht 255.255.255.255 benutze, sondern z.B. 192.168.1.255, sprich nur in das einzelne Subnetz gezielt broadcaste. Heißt aber auch, dass diese Adresse bei jedem Kunden konfiguriert werden muss...

[Captnemo]

Okay, dass du mit

Zitat:

Zitat von jaenicke (Beitrag 1307936)

Wenn das Programm aber beendet wird, bleibt der Port geöffnet.

von außen beendet meinst, dass hatte ich daraus nicht gelesen.

Zitat:

Zitat von jaenicke (Beitrag 1308011)

Längere Verzögerung scheint zu gehen (20 Sekunden). Aber das Problem scheint auch weg zu sein, wenn ich als Broadcastadresse nicht 255.255.255.255 benutze, sondern z.B. 192.168.1.255, sprich nur in das einzelne Subnetz gezielt broadcaste. Heißt aber auch, dass diese Adresse bei jedem Kunden konfiguriert werden muss...

Naja, den Netzwerkteil der IP-Adresse könntest du ja aus der IP-Adresse des Clients herauslesen, um deine Broadcastadresse zu bilden.

Des Weiteren könntest du ja bei beim Öffnen des Ports auf Erfolg prüfen, und das in einer Schleife eine gewisse Zeit wiederholen, bis es halt klappt.

[jaenicke]

Zitat:

Zitat von Captnemo (Beitrag 1308028)

Okay, dass du mit

Zitat:

Zitat von jaenicke (Beitrag 1307936)

Wenn das Programm aber beendet wird, bleibt der Port geöffnet.

von außen beendet meinst, dass hatte ich daraus nicht gelesen.

Nicht immer, aber so lässt es sich am besten reproduzieren. Im echten Betrieb war das nicht so, zumindest nicht immer.

Wiederholen alleine scheint auch nicht zu gehen, aber ich habe eben beobachtet, dass es offenbar nach einem Broadcast klappte, sprich Windows den Socket geschlossen hat. Vielleicht hängt der Socket einfach so lange bis etwas ankommt oder ein Timeout auftritt...

Die IP lässt sich schlecht automatisch bestimmen, denn es sind ja mehrere Netzwerkadapter aktiv, LAN, VPN, LTE, ...
Welcher dann der richtige ist... das kann ich zwar versuchen über den Typ der Verbindung usw., aber ob das dann immer stimmt?

[Captnemo]

Konntest du dieses Verhalten mal mit einem kleinen Testprojekt nachstellen? Vielleicht eines, was du hier posten kannst?

[jaenicke]

Nein, konnte ich nicht.

Ich habe es nun aber nach stundenlanger Suche herausgefunden wann der Port offen bleibt auf diese Weise...

Und zwar startet die Anwendung weitere Toolprogramme. Sobald ein solches Tool nach dem Ende des Programms noch offen ist, bleibt der Port im System belegt.
Ich vermute einmal, das liegt daran, dass Handles ggf. an Kindprozesse übergeben werden können, und somit bis zu deren Ende verwendet werden könnten.