社区
网络编程
帖子详情
iocp关于收包疑问?
EvilGene
2012-07-21 07:54:10
假定IOCP有2个线程 分别是A B
客户1发送 "head!123!充值100!end"(数据很大 )
客户1发送 "head!456!充值200!end"(数据很大 )
在数据比较大的情况会不会出现:
IOCP A线程收到“head!123!” 一半的数据? 另一半数据让B线程收到? (数据很大的情况下)
我习惯得到数据包后 判断是否有end如果没有就进行组包 我怕出现“head!123!充值200end!"
...全文
264
12
打赏
收藏
iocp关于收包疑问?
假定IOCP有2个线程 分别是A B 客户1发送 "head!123!充值100!end"(数据很大 ) 客户1发送 "head!456!充值200!end"(数据很大 ) 在数据比较大的情况会不会出现: IOCP A线程收到“head!123!” 一半的数据? 另一半数据让B线程收到? (数据很大的情况下) 我习惯得到数据包后 判断是否有end如果没有就进行组包 我怕出现“head!123!充值200end!"
复制链接
扫一扫
分享
转发到动态
举报
AI
作业
写回复
配置赞助广告
用AI写文章
12 条
回复
切换为时间正序
请发表友善的回复…
发表回复
打赏红包
luawkk
2012-09-06
打赏
举报
回复
1,看楼上对客户端套接字投递了几次 revc 如果每次收到数据后 才投递下一个的话,就不需要加什么序号
2,如果楼上 在收到 数据之前,投递了 2次以上的 recv 则需要进行 投递序号的处理,否则出现“包的乱序”现象
「已注销」
2012-09-01
打赏
举报
回复
IOCP的 WSAsend和WSArecv还是建议一次投递一个IO请求,这样处理起来简单
ChinaTek
2012-09-01
打赏
举报
回复
学习来了!
翅膀又硬了
2012-07-30
打赏
举报
回复
弄成短连接吧,充值一次就断开。
zxd_0511
2012-07-30
打赏
举报
回复
如果是客户端顺序发送,服务器端每次仅投递一个recv,那么TCP的连接会在底层保证数据包的内部顺序,iocp仅仅是一种io模型,iocp所做的工作仅仅是通知应用程序 数据来了或者数据发送出去了,之所以乱序是因为应用程序多线程从socket buffer中取数据造成的。如果楼主是逐次投递recv,从理论上讲,应该没问题。
zxd_0511
2012-07-30
打赏
举报
回复
不推荐在一个socket上投递多个recv,因为投递多个recv势必要由多个线程去处理,线程间的同步和互斥就成了关键问题,反而复杂了。
我的理解是:在每个socket上仅投递一个recv,接收完数据后再投递recv,这样就不用考虑乱序的问题,也就不会出现“head!123!充值200end!”这种情况。
6楼说的现象可能是由于投递多个recv引起的。
youngwolf
2012-07-25
打赏
举报
回复
带大名顶顶的boost.asio来说,你可以看看它的代码:
boost/asio/write.hpp: 416
的async_write函数的说明,明确指出,用户必须保证,在投递一个async_write之后一直到数据发送完毕,这之间不允许再次投递另一个async_write。
youngwolf
2012-07-25
打赏
举报
回复
不要在同一个套接字上投递多个recv!
服务器的任务不是尽快的响应某个套接字,而是尽量不要太慢的平均的响应每一个套接字。
你多线程recv,不会比单recv快多少。却带来编程的复杂(复杂度远超你想象),因为你收到的包可能完全是乱序的,不光是加个序号组包这么简单,因为还涉及到分包粘包问题(比如一个包,被两个线程收到,你怎么组)。另外,你组包时还得加解锁。
无论你有多少个线程去同时recv,可是网线只有一根,所以根本没用,你只要做到,每次recv到数据的时候,马上拷贝到缓存中,再继续recv,处理逻辑在另外的线程中,从缓存中取数据,然后处理(这是网络编程中服务端基本原则,但CSDN上问问题的人,没见有人遵守过),就不会有效率上的损失。
服务端网络编程其实本质上只做数据在用户与内核之间的拷贝,瓶颈在逻辑处理。
MingoJ
2012-07-25
打赏
举报
回复
不仅会出现断包(分几包收)的问题, 还可能会出现,后面的包先收的问题,如A线程收前半包, 后半包B线程收, 还可能会出现B线程先接收完的问题
完成端口有这个问题, 得自己想办法解决
EvilGene
2012-07-22
打赏
举报
回复
[Quote=引用 2 楼 的回复:]
利用IOCP投递Recv时可以指定completeKey,通过不同的completeKey可以区分不同的客户。
[/Quote]
不是区分客户的问题
那个客户1是销售代理 他发送指令给谁充值的指令 出现 “head!123!充值200end!”
给用户123冲200那就悲剧了
微型蚂蚁
2012-07-21
打赏
举报
回复
利用IOCP投递Recv时可以指定completeKey,通过不同的completeKey可以区分不同的客户。
Eleven
2012-07-21
打赏
举报
回复
有可能,每个包加个序号,然后组包。
在UDP服务器中,线程处理是一次处理40个客户端的最佳方法,还是还有其他更好的方法?
主要问题是:是否需要将上下文信息从一个保留到下一个UPD请求消息?如果不是,即,如果每个UDP请求都包含应答它所需的所有信息,则没有其他理由将请求分发给比使用电源多线程...
实验
IOC
P多线程是否会导致TCP乱序
由于
IOC
P是多线程的,所以有这样的
疑问
:如果WSARecv缓冲的尺寸明显小于一次到达的数据尺寸,线程内出现挂起的情况,那么是否会并发线程处理同一socket的接收数据,进而因线程不同步可能导致后续数据处理在时序上乱序列。 比如说WSARecv的缓冲长度是10字节,
IOC
P开了2+线程,线程逻辑是把接收到的数据显示出来。而一次发来90字节,如果线程内有Sleep,则是否会因为之
IOC
P中多次投递WSASend
关于
IOC
P中是否可以对同一socket连续投递的
疑问
已经很久了,主要的
疑问
在wsaSend是否可以保证数据的完整发送,是否会出现部分发送成功的情况? 网上大多数的建议都是WSASEND采用线性模式,即建立一个发送缓冲,当上一次send完成之后,再进行下一次的投递。那么WSASEND什么情况下会出现部分发送呢? 在MSDN中
IOC
P的列子是对得到的发送的字节值进行了判断的
Windows
IOC
P原理解析:以「智慧餐厅」为喻
本文聚焦
IOC
P的核心机制和基础实现,包含完整的代码示例和流程图解,适合网络编程初学者系统学习。
Epoll和
IOC
P的比较
原来整理过一个《六种Socket I/O模型幽默讲解》,里面是windows的六种socket I/O模型,大学时的windows网络编程就是讲的这几个。今天听了一个网络技术讲座,突然想起了这两个模型还是没搞清楚。 但是,貌似服务器中用的最多的还是linux,相对于windwos最尖端的
IOC
P而言,linux祭出的则是它的Epoll。 Epoll ...
网络编程
18,363
社区成员
64,187
社区内容
发帖
与我相关
我的任务
网络编程
VC/MFC 网络编程
复制链接
扫一扫
分享
社区描述
VC/MFC 网络编程
c++
c语言
开发语言
技术论坛(原bbs)
社区管理员
加入社区
获取链接或二维码
近7日
近30日
至今
加载中
查看更多榜单
社区公告
暂无公告
试试用AI创作助手写篇文章吧
+ 用AI写文章