Wenn unter STCP mehrere Prozesse auf derselben Portnummer lauschen, wird nur der erste Prozess, der an diese Portnummer gebunden ist, benachrichtigt, sobald eine Verbindung angefordert wird. Eine gängige Methode, diese Einschränkung zu umgehen, besteht darin, den Listening-Socket nach Abschluss einer Verbindung zu schließen und anschließend einen neuen Socket zu erstellen, diesen zu binden und erneut auf Verbindungen zu warten. Dadurch wird der Listening-Socket an das Ende der Kette der Listening-Sockets verschoben.
Ab Version 17.1 funktioniert dieses Verfahren nicht mehr, ohne die Standardwerte der STCP-Parameter zu ändern.
Vor Version 17.1 interpretierte STCP die Absicht der Socket-Option SO_REUSEADDR falsch. Diese Option sollte es einem Prozess, der auf Port X lauschte, ermöglichen, sofort neu zu starten, wenn er beendet wurde und das System noch Sockets im TIME_WAIT-Zustand an Port X gebunden hatte. In früheren Versionen von STCP konnte ein Prozess jedoch unabhängig vom Status der an Port X gebundenen Sockets auf Port X lauschen, vorausgesetzt natürlich, dass die Socket-Option SO_REUSEADDR gesetzt war. Dieses Verhalten ermöglicht es zwei verschiedenen Anwendungen, auf dieselbe Portnummer zu lauschen. Wenn die erste Anwendung das Verfahren zur Wiederverwendung des Listening-Ports nutzt oder der Prozess beendet und neu gestartet wird, übernimmt die zweite Anwendung den Port effektiv.
Ab Version 17.1 gibt die Funktion `bind` den Fehler `EADDRINUSE` zurück, es sei denn, alle an den angeforderten Port gebundenen Sockets befinden sich im Zustand `TIME_WAIT` oder der zweite Prozess hat dieselbe Sitzungs-ID wie der erste Prozess. Alle Prozesse, die von demselben Elternprozess gestartet wurden, haben dieselbe Sitzungs-ID. Daher kann ein Prozess mehrere Kindprozesse forken, und alle diese Kindprozesse können auf Port X lauschen.
In Version 17.1 wurden zwei STCP-Parameter hinzugefügt, mit denen das Verhalten von STCP wieder auf das vor Version 17.1 geltende Verhalten zurückgesetzt werden kann. Dabei handelt es sich um „tcp_reuseaddr_action“ und „udp_reuseaddr_action“. Jeder Parameter kann die Werte „safe“ (Standard) und „unsafe“ annehmen. Der Begriff „unsafe“ wird verwendet, da diese Einstellung das oben beschriebene Port-Hijacking ermöglicht.
Mit dem Befehl „analyze_system list_stcp_params“ können Sie die aktuelle Einstellung dieser beiden Parameter anzeigen (Abbildung 1) und mit dem Befehl „set_stcp_param“ die Einstellung ändern (Abbildung 2). Wie alle STCP-Parameter sind Änderungen nur bis zum Neustart des Systems wirksam. Um die Änderung dauerhaft zu machen, muss ein Befehl, der den Parameter auf „unsafe“ setzt, in die Datei „module_start.cm“ oder in die Datei „start_stcp.cm“ eingefügt werden.
analyze_system -request_line 'list_stcp_params tcp_reuseaddr_action' -quit
OpenVOS Release 17.1.0ab, analyze_system Release 17.1.0ab
Aktueller Prozess ist 481, ptep 89B6B740, Noah_Davids.CAC
TCP SO_REUSEADDR-Aktion [safe/unsafe] (tcp_reuseaddr_action) safe
bereit 17:10:29
analyze_system -request_line 'list_stcp_params udp_reuseaddr_action' -quit
OpenVOS Release 17.1.0ab, analyze_system Release 17.1.0ab
Aktueller Prozess ist 481, ptep 89B6B740, Noah_Davids.CAC
UDP SO_REUSEADDR-Aktion [sicher/unsicher] (udp_reuseaddr_action) sicher
bereit 17:11:16
|
| Abbildung 1 – Darstellung der beiden Aktionsparameter von „reuseaddr“ |
analyze_system -request_line 'set_stcp_param tcp_reuseaddr_action unsafe' -quit
OpenVOS Release 17.1.0ab, analyze_system Release 17.1.0ab
Aktueller Prozess ist 481, ptep 89B6B740, Noah_Davids.CAC
Änderung der TCP-SO_REUSEADDR-Aktion (tcp_reuseaddr_action)
von „safe“ auf „unsafe“
bereit 07:30:38
|
| Befehl in Abbildung 2, um „tcp_reuseaddr_action“ auf „unsafe“ zu setzen |