为什么这种情况下会recv会出错？

2015-07-22 09:00:56 482 阅读 AI 写同款 · GEO 优化AI 选题数据监测一键分发 ›

Windows环境下pcl点云库安装配置全流程（精简、有效）本文为Windows配置点云库pcl步骤，具体是win10、visual studio 2017、pcl1.11.1。阅读详情

我用的是TCP协议，在客户端和服务器之间传输数据时，我是这样的：每块数据都有一个数据头，数据头中定义了该数据的长度。然后接着才是真正的数据块。

然后在发送的时候，我是这样的：发送端用两次send函数来发送，一次发送数据头，一次发送真正的数据。接收端也用两次recv来接收。一次接收数据头，数据头收到以后，根据其中给出的长度，再进行第二次recv，接收的长度就是数据头中给出的长度。

可是我发现：这样子的话，会出错。第二次recv收不到数据。

如果发送的时候，把两块数据放在一起，用一次send发送。发现接收端两次recv就能正确收到。或者发送的时候虽分两次send发送。但接收的时候，只用一次recv(当然我预先知道总的长度），也可以把全部数据（包括数据头和数据体）全部收到。

这是怎么回事呢？不管接收端是阻塞方式还是非阻塞方式，好象均如此。

...全文

ASF-YOLO:一种基于注意尺度序列融合的细胞实例分割YOLO模型随着样本制备技术和显微成像技术的快速发展，细胞图像的定量处理和分析在医学、细胞生物学等领域发挥着重要作用。基于卷积神经网络（CNN），可以通过神经网络训练学习不同细胞图像的特征信息，具有很强的泛化性能。两阶段的R-CNN系列[1,2,3]及其一阶段变体[4,5]是实例分割任务的经典CNN基础框架。在最近的研究中，You Only Look Once（YOLO）系列[6,7,8,9]已经成为实时实例分割中速度最快、最准确的模型之一。阅读详情

mbctb

网络编程 18,356 成员 64,161 内容

+ 关注 + 加入社区

切换为时间正序

xian_wwq 2015-07-28

打赏
举报

1。tcp是基于流的,所以必须在业务层自行处理“粘包” 发一个包,接收一次可能得到一个完整的包,也可能收不全; 同理,发两个包,也可能一次就收全了。 2。调试通讯程序时，打断点Debug的方式不可行，建议使用借助文本日志进行调试。

zilaishuichina 2015-07-27

打赏
举报

send 123 可能recv的情况有 recv 1 recv 2 recv 3 或者 recv 12 recv 3 或者 recv 1 recv 23 或者 recv 123 ！！！recv并不一定严格按照你期望的长度来接收数据

南京短暂的春天 2015-07-23

打赏
举报

引用 9 楼 mbctb 的回复:

[quote=引用 8 楼 dcmilan 的回复:] [quote=引用 7 楼 mbctb 的回复:] [quote=引用 6 楼 xiaoxiaoyu85 的回复:] 去看看异步socket和select IO模型后，就明白了。你recv的时候，肯定是随意写了个比你的（数据头 + 数据体）还要大的数字，一次性把数据头和数据体都从接收缓冲区‘拷贝’出来了，第二次recv，就没有数据了。

不是的，我每次recv的时候，都是recv准确的尺寸。目前这个问题虽然没有找到原因，但我找到了解决办法，就是在发送的时候，一次性的发，把数据头和数据体放在一起，一次性用send发送。好象这样就行了。接收端两次recv，也没有问题。接收端非得两次recv不可。因为它第一次只能读出数据头，取出数据体长度，第二次才能读这个数据体长度。反正这样就行了，谢谢大家，以后出问题再研究。看来网络编程真的有不少需要注意的地方。[/quote] 你为什么要接收准确大小的数据呢？你肯定要按最大接收字节数来啊。你只要把规约设计好了，就不会出现这种不匹配的问题。[/quote] 你是说要按最大字节数来接收？我的服务器端是非阻塞模式，客户端，在登录时是阻塞模式，登录以后，设为非阻塞模式。你的意思是：每一次recv的时候，按缓冲区的最大尺寸来接收。至于能收多少，不管管它。然后再分析第一个数据包的头部在哪里，数据体在哪里。第二个数据包的头部在哪里，数据体在哪里。是吗？ [/quote] 对。你要有一个通信规约来说明报文的格式。我写段伪代码 void OnReceive(CBuffer & buffer) { // 检查报文头，假设一帧报文不超过255字节，第一个字节代表报文长度，最后一个字节代表校验和 uint8 len =buffer.at(0); int i = 0; uint8 uSums = 0; for(i = 1 ; i< len; ++i) { uSums += buffer.at(i); } if(uSums != buffer.at(len-1)) { buffer.clear(); return; } // 处理合格报文 // processing.... buffer.remove(len); }

weiaichun 2015-07-23

打赏
举报

你发的快了，产生粘包了，收包的时候自己把他拆下来

mbctb 2015-07-23

打赏
举报

引用 8 楼 dcmilan 的回复:

[quote=引用 7 楼 mbctb 的回复:] [quote=引用 6 楼 xiaoxiaoyu85 的回复:] 去看看异步socket和select IO模型后，就明白了。你recv的时候，肯定是随意写了个比你的（数据头 + 数据体）还要大的数字，一次性把数据头和数据体都从接收缓冲区‘拷贝’出来了，第二次recv，就没有数据了。

南京短暂的春天 2015-07-23

打赏
举报

引用 7 楼 mbctb 的回复:

[quote=引用 6 楼 xiaoxiaoyu85 的回复:] 去看看异步socket和select IO模型后，就明白了。你recv的时候，肯定是随意写了个比你的（数据头 + 数据体）还要大的数字，一次性把数据头和数据体都从接收缓冲区‘拷贝’出来了，第二次recv，就没有数据了。

mbctb 2015-07-23

打赏
举报

引用 6 楼 xiaoxiaoyu85 的回复:

去看看异步socket和select IO模型后，就明白了。你recv的时候，肯定是随意写了个比你的（数据头 + 数据体）还要大的数字，一次性把数据头和数据体都从接收缓冲区‘拷贝’出来了，第二次recv，就没有数据了。

yzm365487848 2015-07-23

打赏
举报

。。。。。。。。。。。。。。。。 send 俩次并不一定非要recv俩次吧！！！！！！就算是send俩次tcp 底层还不是一次性把数据发出去了。具体recv几次是要看你数据量的大小。。 recv的时候判断收到包的长度，如果长度不够就继续 while （nRecvLen < nTotalLen） ::recv(); 。。。

南京短暂的春天 2015-07-22

打赏
举报

正常都是不断的接收，把数据放到一个容器里然后检查报文头的数据长度，把一帧完整的数据从容器取出处理报文往复循环如果碰到错误报文，还要丢弃通信这块还是要做好配合的比如发送的节奏，还要server端处理数据的速度，不能阻塞太久

Magic丶旭 2015-07-22

打赏
举报

把你的代码发给我看看，说不定我给你解决了呢？

96掌门师兄 2015-07-22

打赏
举报

去看看异步socket和select IO模型后，就明白了。你recv的时候，肯定是随意写了个比你的（数据头 + 数据体）还要大的数字，一次性把数据头和数据体都从接收缓冲区‘拷贝’出来了，第二次recv，就没有数据了。

yaozhiyong110 2015-07-22

打赏
举报

不管你是一次发送还是2次发送你都应该判断send的返回值那才代表你真正保存到缓冲区的数据是多少像你说的这种情况你分2次send 也许第二次send已经失败了所以你不管几次recv都收不完数据(因为你第二次的数据根本就没发送成功) recv同理 ps: send返回失败可以根据getlasterror判断错误一般都是发送太快你就需要中间sleep下

么特里亚 2015-07-22

打赏
举报

发完第一次你加上sleep试试

赵4老师 2015-07-22

打赏
举报

不知道有多少前人掉在TCP Socket send(人多)send(病少)send(财富) recv(人多病)recv(少财富) 陷阱里面啊！ http://bbs.csdn.net/topics/380167545

为什么这种情况下会recv会出错？

相关推荐