---以前一直困惑为什么很多服务器程序都那么写,的确在windows下没有必要.其他系统下面就很有必要了
经常有这样的情况,调用send成功了,可是对端就是没有收到,甚至对方已经关机了,本端看到端口还是正常的,send一次也是正常的....大坑 要注意, TCP socket是全双工的. 发送和接收是可以独立的.
对端关闭发送端并不代表它不能接收数据, 因此你单靠write是无法检测到对端关闭了发送端的。
对端关闭发送端相当于告诉你，它要发送给你的数据都发送完了，没有更多的数据需要发送了。
对端关闭它的发送端时, 你这边的读取端就会收到 EOF(即 read返回0), 你就知道对端已经没有数据给你了, 你要根据实际情况来决定是否关闭发送端。
有正常断开和非正常断开
正常断开，会收到singal
非正常断开，tcp keep-live或者应用层心跳 其实可以站高一点，从业务逻辑的角度来看，我们的目的是完成信息交流，一般是发送一个消息出去，然后等待一个应答，
只要超时时间内等不到应答，就认为失败，按照失败的逻辑进行处理。
至于失败的原因，是对方关闭链接，还是对方断电了，还是这边发送失败了，还是甚至connect都没有成功，其实并不是那么重要。
当然，从查找原因的角度来说，程序最好还是要记录具体的原因，但这个真的对业务逻辑处理流程不产生影响
evaspring 发表于 2016-08-19 17:16
看了好几个网络库 都是通过 read() == 0 来判定连接断开的
这个不一定表示链接断开。我经常在没断开的sock中发现read()==0;
本帖最后由 yulihua49 于 2017-01-16 12:25 编辑
kaede_1 发表于 2016-08-19 15:10
最近纠结于两个小问题，哪位大牛帮忙解答一下，不胜感激
1.客户端给服务端发送消息，一端时间后服务端执行 ...
你的逻辑是错误的。
1.服务器收完不需要关闭socket。何时关闭应该是事先约定的。
2.客户端无需事先知道服务器是否关闭，等通信出错后进行错误处理即可。
3.发送信息大多数不知道是否成功，你需要一个确认的流程，包含一个超时处理逻辑。
第3条，我在讲解交易中间件时的确说过发送成功与否无需确认，只要交易完成时回覆。客户端只需验证交易完成确认信息即可。超过一定时限没有回覆即认为交易失败。
即，服务器收完信息，处理完成并回覆之前是不能关闭socket的。
客户端在发送第一个消息之后，没有得到回覆之前是不能发送第二个消息的。
客户端发送信息后，就要接收回覆，网络故障是在接收时发现的。
以上是半双工的。全双工的服务器就更不应该随便关闭socket了，应该继续接收客户端请求，直到双方约定的关闭条件。
各位大牛，我指的是发送，而不是读取
页:
1
[2]