Passer au contenu principal

De temps à autre, quelqu’un pose la question suivante : « Nous avons ajouté le port de notre application au fichier services et maintenant une autre application l’utilise – pourquoi ? ». La réponse est simple : le fichier services ne réserve pas les numéros de port. Ce fichier existe pour permettre aux applications d’appeler la fonction getservbyname afin de trouver le numéro de port associé à un service, ou d’appeler la fonction getservbyport pour trouver le nom d’un service associé à un numéro de port. Rien n'empêche deux services différents d'être mappés au même numéro de port, bien que la fonction getservbyport ne renvoie que le premier. Il n'est pas non plus obligatoire qu'une application appelle getservbyname pour déterminer quel port elle doit utiliser. Un développeur d'application peut simplement coder en dur un numéro de port ou permettre qu'il soit saisi en tant que paramètre.

Il n'y a aucun moyen de réserver un numéro de port, si ce n'est de l'utiliser, et ce uniquement si vous ne configurez pas l'option de socket REUSEADDR ; lancez donc votre application dès que possible après le démarrage de STCP, avant qu'une autre application ne s'empare de votre port.

 

Parfois, le problème ne vient pas d'une autre application serveur, mais d'une application cliente. La plupart des applications clientes ne se connectent pas à un port local spécifique, mais comme un port local est nécessaire, STCP en attribue un à partir de la plage de ports dynamiques (49152 – 65535). Si votre application utilise un port de cette plage, je vous suggère de le modifier pour qu'il utilise un port de la plage enregistrée, 1024-49151. Ces ports ne seront utilisés que si une application s'y connecte explicitement.

 

Bon, supposons qu'une autre application utilise le port de votre application ; comment pouvez-vous identifier de quelle application il s'agit et, surtout, qui l'a lancée ? Il s'agit d'un processus en trois étapes :

 

  1. Exécutez la commande “netstat -numeric -all_sockets -PCB_addr” et identifier l'intrus ; dans ce cas précis, le numéro de port qui m'intéresse est le 13592.
netstat -numeric -all_sockets -PCB_addr
Active connections (including servers)
PCB       Proto Recv-Q Send-Q Local Address Foreign Address
(state)
. . .
8e3aa300 tcp        0      0 *:13592          *:*          LISTEN
. . .
ready 13:50:12
  1. Exécutez la commande

“analyze_system -request_line 'match dv; dump_onetcb 8e3aa300' -quit”

en transmettant à la requête `dump_onetcb` le PCB de l'intrus, 8e3aa300. Cela permet d'identifier le périphérique STCP associé à la socket.
OpenVOS Release 17.0.1aj, analyze_system Release 17.0.1aj
Current process is 664, ptep 8E0EE800, Noah_Davids.CAC
sth_dvtx                 = 121 (stcp.m16_202)
  1. Exécutez la commande “who_locked #stcp.m16_202” pour déterminer quel processus utilise le périphérique.
stcp.m16_202:
Object is write locked by Barney_Rubble.Dev (login) on module
%vs#m1
executing stcp_calls.pm.

 

Et voilà, il ne vous reste plus qu'à contacter ce Barney Rubble et à lui suggérer poliment d'utiliser un autre numéro de port.