.Net Socket Read 功能阻塞问题答案

【问题标题】：.Net Socket Read function blocking issue.Net Socket Read 功能阻塞问题
【发布时间】：2013-10-07 11:05:30
【问题描述】：

我在 C#.Net 中有客户端-服务器应用程序，为此我正在使用 Tcp 套接字。我已经使用以下函数来积极关闭套接字对象。

void CloseSocket(Socket socket)
{
      if(socket != null)
      {
           socket.ShutDown(ocketShutdown.Both);
           socket.Close();
      } 
}

在正常情况下，此函数完美运行，我的方法返回读取函数返回的 0 个字节。

但是每当客户端进程被taskmanager服务器程序终止时，就会阻塞到网络流的读取功能中。

如何解决这个读取阻塞功能？我不想使用 AsyncRead 函数，因为整个项目使用阻塞策略，所以现在写我不能将它更改为异步模式。

谢谢，提前。

【问题讨论】：

您能否澄清一下：您发布的代码 是否阻塞了问题？还是说读取代码（未显示）没有检测到僵尸连接？
你能发布你用来接收的代码吗？我希望在这种情况下阻塞操作会被中断。

标签： c# .net sockets network-programming

【解决方案1】：

我假设你的意思是，当客户端没有完全关闭连接时，服务器最终可能会无限期地阻塞在Read，即使客户端有实际上突然终止。如果是这样：是的，那会发生。所以如果你想使用同步读取方法，你应该使用超时，特别是ReceiveTimeout。如果您有一个多消息协议，则可能值得定期添加某种心跳消息，以允许您从空闲连接中正确识别真正的僵尸（例如：如果您每分钟发送一次心跳，而您没有看到任何连接上的活动 3 分钟，用铲子敲击它）。

【讨论】：

不应该关闭套接字中断块吗？
@C.Evenhuis 我的理解是他正在杀死客户端，因此他的代码 sn-p 永远不会运行。一个不同的问题是为什么杀死一个进程不会终止/RST它应该的TCP连接。
@C.Evenhuis 您的意思是在检查最后一个活动的常规“扫描”线程中吗？如果是这样，是的，这可能还会导致调用Receive / Read的线程出现一些可检测的退出条件@
@usr 老实说，我从不依赖套接字正确关闭。因为在现实世界中：他们没有。尤其是当两端之间有很多移动部件（隧道/VPN、负载平衡器、中继等）时。
@MarcGravell 我的意思是当有一个阻塞的Receive() 方法并且你Close() 来自另一个线程的套接字时，通常会抛出一个异常“阻塞操作被对 WSACancelBlockingCall 的调用中断”。不过，我认为@usr 正在做某事。

【解决方案2】：

**you can try this may help you**


    public void close()
        {
            if(clientSocket != null )
            {
                sendCommand("QUIT");
            }

            cleanup();

        }

    private void cleanup()
        {
            if(clientSocket!=null)
            {
                clientSocket.Close();
                clientSocket = null;
            }
            logined = false;
        }

【讨论】：

发送QUIT 消息很大程度上取决于对协议是否明智...
当进程被任务管理器终止时，无论退出会话，它都不会损害任何东西。