无法再连接到仍被进程监听的本地端口

时间:2015-03-18 11:56:14

标签: c++ sockets tcp

我有一个服务器应用程序(unimrcpserver.exe)正在回答来自客户端进程的请求。此服务器进程侦听多个端口。 使用netstat -a命令,我的进程获得以下行。

  TCP    192.168.10.65:2544     MERTB-PC:0             LISTENING  
  TCP    192.168.10.65:2554     MERTB-PC:0             LISTENING  
  TCP    192.168.10.65:9060     MERTB-PC:0             LISTENING  

(netstat输出很长我只把相关的行放在这里)

通常,当系统工作时,我从这些端口向服务器发出请求,并且每个端口都正常工作。

当我进行压力测试时,我看到系统不再响应我通过端口2554发出的请求的情况。  netstat -a仍然给我上面的行,所以服务器仍然以某种方式监听这个端口。当我在同一台机器上运行telnet时,它会出错:

telnet 192.168.10.65 2554  
  Connecting To 192.168.10.65...Could not open connection to the host, on port 2554: Connect failed

我还用c ++编写了一个简单的程序,以获得系统生成的connect()请求的确切错误消息。这次我收到以下错误:

No connection could be made because the target machine actively refused it

其他信息:所有内容都在同一台Windows计算机上。防火墙已禁用。当我正在进行同时发送多个请求的压力测试时,这种情况只发生过一次。在情况发生之前,系统处理了大约13000个请求,大约需要半个小时。

所以问题是:这种情况怎么会发生?该端口被netstat报告为“LISTENING”但我无法连接到它。如果它可能是由编程错误引起的,那么什么样的错误会导致这种行为?

2 个答案:

答案 0 :(得分:2)

在以下几种情况下,可以“主动拒绝”新连接:

  1. IP上没有LISTENING套接字:端口连接到。

  2. 有一个LISTENING套接字,但其待处理连接的积压已满,因此当时无法接受新连接。

  3. 防火墙阻止了它。虽然防火墙更可能使用不同的错误,但如果它发送错误的话。

  4. 由于存在LISTENING套接字,#2是最可能/常见的情况。如果是这样,这意味着服务器应用程序不会足够快地接受来自其待办事项的客户端(如果有的话)。

    客户无法区分这些条件。它所能做的就是检测连接失败 - WSAECONNREFUSEDECONNREFUSED,具体取决于平台 - 稍后再试。

答案 1 :(得分:1)

  
    

所以问题是:这种情况怎么会发生?正在报告端口>> as" LISTENING"与netstat但我无法连接到它。如果它可能由编程错误引起>>什么样的错误会导致这种行为?

  

是的,这可能是由服务器上的编程错误引起的。当服务器的监听线程死锁时,我已经看到它发生了。套接字的状态是" listen"但是如果侦听线程具有某种全局状态并且在等待互斥锁被释放的其他线程上被阻塞,则会遇到此问题。 此外,像其他人一样,如果CPU由于压力测试而加载,并且可能导致服务器拒绝连接,因为线程可能正忙于处理并且监听线程从未有机会接受连接。