问题描述
在.net平台下使用c#进行tcp通信，客户端发送命令服务器端收到后执行命令，服务器端执行时间大概几个小时，然后返回给客户端结果。在此期间客户端使用阻塞的方式Read方法读取，为了防止TCP在长链接时断开，我启用了c#tcp中的KeepAlive机制,每三分钟发一次心跳包。但是过了一个多小时read()方法触发异常，“无法从传输连接中读取数据：你的主机中的软件终止了一个已建立的连接。”，我用wireshark查看，发现触发异常时候心跳包还能正常接收。不知道什么原因导致read异常，求大神解答，在线等！！！！
解决方案
解决方案二：
这个问题应该是服务端断开的，而不是客户端心跳这里。应该先判断是否已经断开连接，然后做好判断read方法是否应该退出
解决方案三：
楼主的连接能够维持几个小时已经成功了,对于这样的断线应该有重新连接的功能,当断线频繁的时候再考虑具体的原因.
解决方案四：
服务器端发回了数据，客户端一直收不到，然后服务器端就超时了，客户端也死了
解决方案五：
话说Read是什么方法？
解决方案六：
首先，不应该阻塞。其次，服务器端不应该只认一个会话。当客户端发现需要重连时，就会在另外一个会话中重新连接。那么服务器端就应该把返回消息发给新的会话。第三，客户端在收到服务器推送的消息时，判断这个消息的性质。如果是返回，就执行其之前已经注册过的回调处理方法（显然它与跟服务器的会话无关，而是跟消息本身唯一编号有关）。
解决方案七：
首先，不应该阻塞。其次，服务器端不应该只认一个会话。当客户端发现需要重连时，就会在另外一个会话中重新连接。那么服务器端就应该把返回消息发给新的会话。第三，客户端在收到服务器推送的消息时，判断这个消息的性质。如果是返回，就执行其之前已经注册过的回调处理方法（显然它与跟服务器的会话无关，而是跟消息本身唯一编号有关）。
解决方案八：
客户端不用扯上什么“KeepAlive机制”。它在发现无法收或者发消息时，重连服务器就行了。必须自动重连，你有这个机制吗？