Partager la charge - Écoute de plusieurs processus sur le même numéro de port

Dans le cadre du STCP, lorsque plusieurs processus écoutent sur le même numéro de port, seul le premier processus lié au numéro de port est notifié lorsqu'une connexion est demandée. Une façon courante de contourner cette restriction est de fermer la prise d'écoute lorsqu'une connexion est terminée, puis de créer une nouvelle prise, de la lier et de l'écouter à nouveau. Cela place la prise d'écoute à la fin de la chaîne des prises d'écoute.

À partir du point 17.1, cette procédure ne fonctionnera plus sans modifier les valeurs par défaut des paramètres du PCTT.

Avant le 17.1, le STCP a mal interprété l'intention de l'option de socket SO_REUSEADDR. L'intention de cette option était de permettre à un processus qui écoutait sur le port X de redémarrer immédiatement s'il était terminé et que le système avait encore des sockets liées au port X dans un état TIME_WAIT. Cependant, les versions précédentes de STCP permettaient à un processus d'écouter sur le port X quel que soit l'état des sockets existantes liées au port X, en supposant bien sûr que l'option de socket SO_REUSEADDR était définie. Ce comportement permet à deux applications différentes d'écouter le même numéro de port. Si la première application utilise la procédure de recyclage du port d'écoute ou si le processus est interrompu et redémarré, la seconde application détournera effectivement le port.

À partir de la version 17.1, la fonction de liaison renvoie l'erreur EADDRINUSE, sauf si toutes les sockets liées sur le port demandé sont dans un état TIME_WAIT ; ou si le deuxième processus a le même ID de session que le premier processus. Tous les processus lancés à partir du même processus parent auront le même ID de session, de sorte qu'un processus peut bifurquer vers plusieurs processus fils et que tous ces fils peuvent écouter sur le port X.

Deux paramètres du STCP ont été ajoutés dans la version 17.1 et peuvent être utilisés pour modifier le comportement du STCP afin de revenir au comportement antérieur à la version 17.1 : tcp_reuseaddr_action et udp_reuseaddr_action. Chaque paramètre a les valeurs "safe" (par défaut) et "unsafe". Le terme "unsafe" est utilisé parce que le paramètre permettra le détournement de port décrit ci-dessus.

Vous pouvez utiliser le système de requête analyze list_stcp_params pour afficher le réglage actuel de ces deux paramètres (figure 1) et la requête set_stcp_param pour modifier le réglage (figure 2). Comme tous les paramètres STCP, les modifications ne sont effectives que jusqu'au redémarrage du système. Pour que la modification soit permanente, une commande fixant le paramètre à unsafe doit être placée dans le fichier module_start.cm ou dans le fichier start_stcp.cm.

analyze_system -request_line 'list_stcp_params tcp_reuseaddr_action' -quit
OpenVOS version 17.1.0ab, analyze_system version 17.1.0ab
La procédure actuelle est la 481, étape 89B6B740, Noah_Davids.CAC

TCP SO_REUSEADDR action [safe/unsafe] (tcp_reuseaddr_action) safe

prêt 17:10:29

analyze_system -request_line 'list_stcp_params udp_reuseaddr_action' -quit
OpenVOS version 17.1.0ab, analyze_system version 17.1.0ab
La procédure actuelle est la 481, étape 89B6B740, Noah_Davids.CAC

UDP SO_REUSEADDR action [safe/unsafe] (udp_reuseaddr_action) safe

prêt 17:11:16

analyze_system -request_line 'set_stcp_param tcp_reuseaddr_action unsafe' -quit
OpenVOS version 17.1.0ab, analyze_system version 17.1.0ab
La procédure actuelle est la 481, étape 89B6B740, Noah_Davids.CAC

Modification de l'action SO_REUSEADDR du TCP (tcp_reuseaddr_action)
de la sécurité à l'insécurité
prêt 07:30:38