跳转至主要内容

时不时有人会问以下问题:"我们把我们的应用程序端口添加到服务文件中,现在有其他应用程序在使用它--为什么"。答案是,因为服务文件不保留端口号。服务文件的存在是为了让应用程序可以调用 getservbyname 函数来查找与服务相关联的端口号, 或者调用 getservbyport 函数来查找与端口号相关联的服务名称。没有什么可以阻止两个不同的服务映射到同一个端口号,尽管getervbyport函数只会返回第一个。也没有要求应用程序必须调用 getservbyname 来找出它应该使用的端口。应用程序开发人员可以直接对端口号进行硬编码, 或允许将其作为参数输入。

没有办法保留端口号--除了使用它,而且只有在不设置REUSEADDR套接字选项的情况下才能使用;所以在STCP启动后,在其他应用程序抢占你的端口之前,尽快启动你的应用程序。

 

有时,罪魁祸首不是另一个服务器应用程序,而是一个客户端应用程序。大多数客户端应用程序并不绑定到特定的本地端口,但是由于需要本地端口,STCP会从动态端口范围(49152 - 65535)中分配一个端口。如果你的应用程序使用这个范围内的端口,我建议你把它改为使用注册范围内的端口,1024-49151。这些端口只有在应用程序明确绑定到它们时才会被使用。

 

好吧,让我们假设有另一个应用程序在使用您的应用程序的 port;如何识别它是什么应用程序,更重要的是谁启动了它?这是一个三步走的过程。

 

  1. 运行以下命令 “netstat -numeric -all_sockets -PCB_addr” 并识别干扰者,在这种情况下,我感兴趣的端口号是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. 运行以下命令

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

传递给dump_onetcb请求的interloper的PCB,8e3aa300。这标识了与插座相关联的STCP设备。
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. 运行以下命令 “who_locked #stcp.m16_202” 以确定使用该设备的是什么流程。
stcp.m16_202:
Object is write locked by Barney_Rubble.Dev (login) on module
%vs#m1
executing stcp_calls.pm.

 

你现在要做的就是联系这个Barney Rubble 礼貌地建议他使用不同的端口号。

© 2024Stratus Technologies.