Lastverteilung - Mehrere Prozesse, die auf dieselbe Anschlussnummer warten

Unter STCP wird bei mehreren Prozessen, die auf dieselbe Anschlussnummer hören, nur der erste Prozess, der an die Anschlussnummer gebunden ist, benachrichtigt, wenn eine Verbindung angefordert wird. Eine gängige Möglichkeit, diese Einschränkung zu umgehen, besteht darin, den lauschenden Socket zu schließen, wenn eine Verbindung beendet ist, und dann einen neuen Socket zu erstellen und erneut zu binden und zu lauschen. Dadurch wird der abhörende Socket an das Ende der Kette von abhörenden Sockets gesetzt.

Ab 17.1 funktioniert dieses Verfahren nicht mehr, ohne dass die Standardwerte der STCP-Parameter geändert werden.

Vor Version 17.1 hat STCP die Absicht der Socket-Option SO_REUSEADDR falsch interpretiert. Die Absicht dieser Option war es, einem Prozess, der Port X abhörte, einen sofortigen Neustart zu ermöglichen, wenn er beendet wurde und das System noch Sockets hatte, die an Port X in einem TIME_WAIT-Zustand gebunden waren. In den früheren Versionen von STCP konnte ein Prozess jedoch unabhängig vom Zustand der an Port X gebundenen Sockets an 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 hören. Wenn die erste Anwendung das Verfahren zum Abhören des Ports verwendet oder der Prozess beendet und neu gestartet wird, entführt die zweite Anwendung den Port effektiv.

Ab Version 17.1 gibt die bind-Funktion 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 die gleiche Sitzungs-ID wie der erste Prozess. Alle Prozesse, die von demselben übergeordneten Prozess gestartet werden, haben dieselbe Sitzungs-ID, so dass ein Prozess mehrere untergeordnete Prozesse forken kann und alle diese untergeordneten Prozesse auf Port X hören können.

In Version 17.1 wurden zwei STCP-Parameter hinzugefügt, mit denen das Verhalten von STCP auf das Verhalten vor 17.1 zurückgesetzt werden kann: tcp_reuseaddr_action und udp_reuseaddr_action. Jeder Parameter hat die Werte "safe" (Standard) und "unsafe". Der Begriff "unsafe" wird verwendet, weil die Einstellung das oben beschriebene Port-Hijacking ermöglicht.

Sie können die analyze_system-Abfrage list_stcp_params verwenden, um die aktuelle Einstellung dieser beiden Parameter anzuzeigen (Abbildung 1), und die Abfrage set_stcp_param, um die Einstellung zu ändern (Abbildung 2). Wie alle STCP-Parameter sind Änderungen nur bis zum Neustart des Systems wirksam. Um die Änderung dauerhaft zu machen, muss also ein Befehl, der den Parameter auf unsicher setzt, in der Datei module_start.cm oder in der Datei start_stcp.cm platziert 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 [safe/unsafe] (udp_reuseaddr_action) safe

bereit 17:11:16

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

Ändern der TCP SO_REUSEADDR-Aktion (tcp_reuseaddr_action)
von sicher auf unsicher
bereit 07:30:38