msdn 说recv返回0是接收完成了,用的这个
apache默认正常断开连接的时间是15秒,我recv一直阻塞在那等15秒才能返回0,
如果设置了超时时间它倒是到时间返回了,不过拿到的结果是超时了,也不知道有没有接收完成
服务器端都是别人的,我不能控制的
不知道大家有啥好的方法判断是否接收完成,别等时间那么长
21 个解决方案
#1
#2
tcp的标准是返回0,这时候说明服务端调用shutdown函数
#3
楼上的那有啥方法判断的
总不能等那么长时间吧
总不能等那么长时间吧
#4
自己顶
#5
咋没人回呢
#6
#7
#8
自己顶
#9
如果不想等,可以设置为非阻塞的啊。为什么设置为阻塞的还不想等待呢?
#10
这个难道没办法么?
#11
这个难道没办法么?????
#12
#13
如果对方半天不给你shutdown,只能客户端自己想办法,比如自己定个超时,超过时间自己就close掉,不过这就是强制关闭而不是从容关闭了
#14
1,通信有协议,你收到完整的应答了还等什么?
2,read返回0,表明对端关闭。
2,服务端改不了,你就不写了吗?在1,2的基础上,设置客户端超时,无论你用 SO_RCVTIMEO 还是使用select监听,编码实现超时检查,都是你的选择,你有权利做一切。
2,read返回0,表明对端关闭。
2,服务端改不了,你就不写了吗?在1,2的基础上,设置客户端超时,无论你用 SO_RCVTIMEO 还是使用select监听,编码实现超时检查,都是你的选择,你有权利做一切。
#15
他超时了,你怎么能知道数据是否接受完成了
如果数据发送一半超时了,接受的数据肯定不完整
如果数据发送一半超时了,接受的数据肯定不完整
#16
作为有格式有协议的数据,你自己应该能判断是否接全了
#17
如果接受的数据没有什么固定的格式的话,就不知道数据是否接受完了
如果一个http服务器返回一个txt格式的文本文件,那就判断不出它什么时候接受完成了
如果一个http服务器返回一个txt格式的文本文件,那就判断不出它什么时候接受完成了
#18
我不太懂http服务器,当你向他请求任意格式数据的时候,是发裸数据还是做了个封装,比如告诉你个要接受的长度之类的
如果有封装自然好办,没有的话没什么好办法
如果有封装自然好办,没有的话没什么好办法
#19
Content-Length: 72
http协议头部是这个指示数据长度的
大部分http服务器都会有的,
但是有些它就没有这个信息
这样应该就判断不出来数据是否接收完整了
协议里面也没有规定碰到哪个标示就表明数据接受完成了
http协议头部是这个指示数据长度的
大部分http服务器都会有的,
但是有些它就没有这个信息
这样应该就判断不出来数据是否接收完整了
协议里面也没有规定碰到哪个标示就表明数据接受完成了
#20
这就要看你用户对完整性的要求了
你的程序肯定有异常处理吧,你有没有考虑这么一种情况,就是传输过程中断网,这时候数据肯定不完整,你如何处理的,丢掉?还是也给用户?
当你无法判断数据完整性,又达到了超时时间,这时候用的策略应该和断网时一样
浏览器这时候的做法是接到多少用多少
你的程序肯定有异常处理吧,你有没有考虑这么一种情况,就是传输过程中断网,这时候数据肯定不完整,你如何处理的,丢掉?还是也给用户?
当你无法判断数据完整性,又达到了超时时间,这时候用的策略应该和断网时一样
浏览器这时候的做法是接到多少用多少
#21
我抓过用ie浏览百度首页的包,百度是60秒那样才发送关闭socket的请求,
ie好像一直在那等着,直到正常关闭
ie好像也是没有很好的办法处理是否接受完成,就一直在那等着
ie好像一直在那等着,直到正常关闭
ie好像也是没有很好的办法处理是否接受完成,就一直在那等着
#1
#2
tcp的标准是返回0,这时候说明服务端调用shutdown函数
#3
楼上的那有啥方法判断的
总不能等那么长时间吧
总不能等那么长时间吧
#4
自己顶
#5
咋没人回呢
#6
#7
#8
自己顶
#9
如果不想等,可以设置为非阻塞的啊。为什么设置为阻塞的还不想等待呢?
#10
这个难道没办法么?
#11
这个难道没办法么?????
#12
#13
如果对方半天不给你shutdown,只能客户端自己想办法,比如自己定个超时,超过时间自己就close掉,不过这就是强制关闭而不是从容关闭了
#14
1,通信有协议,你收到完整的应答了还等什么?
2,read返回0,表明对端关闭。
2,服务端改不了,你就不写了吗?在1,2的基础上,设置客户端超时,无论你用 SO_RCVTIMEO 还是使用select监听,编码实现超时检查,都是你的选择,你有权利做一切。
2,read返回0,表明对端关闭。
2,服务端改不了,你就不写了吗?在1,2的基础上,设置客户端超时,无论你用 SO_RCVTIMEO 还是使用select监听,编码实现超时检查,都是你的选择,你有权利做一切。
#15
他超时了,你怎么能知道数据是否接受完成了
如果数据发送一半超时了,接受的数据肯定不完整
如果数据发送一半超时了,接受的数据肯定不完整
#16
作为有格式有协议的数据,你自己应该能判断是否接全了
#17
如果接受的数据没有什么固定的格式的话,就不知道数据是否接受完了
如果一个http服务器返回一个txt格式的文本文件,那就判断不出它什么时候接受完成了
如果一个http服务器返回一个txt格式的文本文件,那就判断不出它什么时候接受完成了
#18
我不太懂http服务器,当你向他请求任意格式数据的时候,是发裸数据还是做了个封装,比如告诉你个要接受的长度之类的
如果有封装自然好办,没有的话没什么好办法
如果有封装自然好办,没有的话没什么好办法
#19
Content-Length: 72
http协议头部是这个指示数据长度的
大部分http服务器都会有的,
但是有些它就没有这个信息
这样应该就判断不出来数据是否接收完整了
协议里面也没有规定碰到哪个标示就表明数据接受完成了
http协议头部是这个指示数据长度的
大部分http服务器都会有的,
但是有些它就没有这个信息
这样应该就判断不出来数据是否接收完整了
协议里面也没有规定碰到哪个标示就表明数据接受完成了
#20
这就要看你用户对完整性的要求了
你的程序肯定有异常处理吧,你有没有考虑这么一种情况,就是传输过程中断网,这时候数据肯定不完整,你如何处理的,丢掉?还是也给用户?
当你无法判断数据完整性,又达到了超时时间,这时候用的策略应该和断网时一样
浏览器这时候的做法是接到多少用多少
你的程序肯定有异常处理吧,你有没有考虑这么一种情况,就是传输过程中断网,这时候数据肯定不完整,你如何处理的,丢掉?还是也给用户?
当你无法判断数据完整性,又达到了超时时间,这时候用的策略应该和断网时一样
浏览器这时候的做法是接到多少用多少
#21
我抓过用ie浏览百度首页的包,百度是60秒那样才发送关闭socket的请求,
ie好像一直在那等着,直到正常关闭
ie好像也是没有很好的办法处理是否接受完成,就一直在那等着
ie好像一直在那等着,直到正常关闭
ie好像也是没有很好的办法处理是否接受完成,就一直在那等着