IOCP 多线程 接收 问题

[songtao_01]

问个问题，用iocp,多线程模式下接受的时候会乱序吗？就比如一个连接先后发了两次数据：1：abcdef 2:hijklm;
然后接受到的时候，会不会是abcklmdefhij呢？如果会，如何解决。如果不会，原因是什么？粘包好解决，就是这乱序。。。。另外这种乱序我在实验过程中没出现过，但是理论上可能会出现吧，我说的对吗？敬请帮助！

[xghuzd]

是可以提高效率:因为不用线程收一个,再投下一个WSARECV();
CPU就调用一次就可以接收两次的数据了.

[scq2099yt]

不明白为什么要多个线程里接受来自同一个端口的数据，这样能给你带来什么？

[lhsxsh]

服务线程和CUP的多少有关系。
这样才能使用CUP工作的更好

[makui]

[Quote=引用 17 楼 hu_zhi_de 的回复:]
是可以提高效率:因为不用线程收一个,再投下一个WSARECV();
CPU就调用一次就可以接收两次的数据了.
[/Quote]

我觉得你这个有两个方面的问题需要考虑:
1.第一次调用的WSARecv接收的的数据是否需要在第二次接收到的数据之前处理呢?
2.假如第一次你需要读取1024的数据,你实际读到你的数据可能大于这个值;那你第二次读取到的数据怎么处理?

按你想的,还不如把WSABuf设大一点减少调用的次数

[fengge8ylf]

投递一次请求 等这个请求完成后再投递下一个请求 即使是多线程也不会乱序

[fengge8ylf]

我不明白的是发送的时候 是不是等上一个发送成功了 再投递 还是不必理上一个发送 我看BOOST的ASIO 好像可以连续投递发送
不敢确定

[auly403]

[Quote=引用 16 楼 songtao_01 的回复:]
引用 15 楼 scq2099yt 的回复:

不明白为什么要多个线程里接受来自同一个端口的数据，这样能给你带来什么？

可以带来效率。
[/Quote]


持怀疑态度，
除非接收的线程你要处理很多工作，比如检验，解密，之类，
那就可以带来效率

[hwsts2]

在一个连见上同时投递多个请求的问题:
其实无论你投递多少个请求,在最下面也是顺序完成请求的,
一般情况下你会发现你的数据都会如你所愿的接受回来,不会存在多大问题

但是有一个种情况你是很难处理的,在Recv端同时投递A,B2个请求, Client端发送
1000字节数据,结果地层接受到 500字节的时候缓冲区满了,
这个时候,你第一个请求A会顺利的返回,但是接受到的字节是 500个,也就是你
还要继续发送请求C才能接,受到剩余的数据,但是这个时候 你在发送一个请求
C的话,那么这个请求会被排在第二个请求B的后面,也就是说B会把剩余的500字
节接收回来.

还有IOCP的设计目的,是处理海量连接,而不是在单连接的数据处理效率

[songtao_01]

[Quote=引用 23 楼 hwsts2 的回复:]
在一个连见上同时投递多个请求的问题:
其实无论你投递多少个请求,在最下面也是顺序完成请求的,
一般情况下你会发现你的数据都会如你所愿的接受回来,不会存在多大问题

但是有一个种情况你是很难处理的,在Recv端同时投递A,B2个请求, Client端发送
1000字节数据,结果地层接受到 500字节的时候缓冲区满了,
这个时候,你第一个请求A会顺利的返回,但是接受到的字节是 500个,也就是你
还要继续发送请求C才能接,受到剩余的数…
[/Quote]

对,我也是觉得如果真出现这种情况的话,就不好处理了,加标示也没用

人呢,多讨论啊

我看游戏服务端代码里的好像没有处理什么乱序问题,难道真的不会乱?

[allix123]

我想请问一下，SOCKET中RecvBuf里面它开设有多大，我听说是8192最大？
也是我们现在所做的SOCKET编程的send or recv是从操作系统里面为这个SOCKET开设的BUFFER中以送或接收数据，

是这样理解吗？

[Leo_red]

[Quote=引用 3 楼 hwsts2 的回复:]
如果你能保证 发送端发送数据是有序的，那么到达接受端缓冲区内，
数据都是有序的，不会乱序，这是TCP协议规定的
[/Quote]

同意，顺序由TCP协议底层保证，你按照顺序发，就肯定按照顺序收到的。
实际应用中也不会乱序，唯一的问题是你如何操作缓冲区。

你按照abcdefg来发送，收到的顺序肯定是abcdefg。你所说的一个线程收了abcd正往缓冲区里面写，另外一个线程收了efg也往里面写，就会乱。这显然是你对共享缓冲区的互斥没有控制啊，对这个缓冲区的操作做好互斥，肯定没有你担心的问题。

[songtao_01]

[Quote=引用 26 楼 Leo_red 的回复:]

同意，顺序由TCP协议底层保证，你按照顺序发，就肯定按照顺序收到的。
实际应用中也不会乱序，唯一的问题是你如何操作缓冲区。

你按照abcdefg来发送，收到的顺序肯定是abcdefg。你所说的一个线程收了abcd正往缓冲区里面写，另外一个线程收了efg也往里面写，就会乱。这显然…
[/Quote]
你误会我的意思了,我的意思是abcd已经写入缓存了,然后另一个线程收到了klm,然后klm往缓存写那不是就乱了

[songtao_01]

[Quote=引用 28 楼 Leo_red 的回复:]
你再往同一个缓存里面写，就接着刚才已经写了的位置写喽，不然从缓冲区的头开始写，不就吧刚才写的东西冲掉了？
这个和粘包处理的方法一样嘛
[/Quote]
大佬,你又误会了,我意思说的是发过来的两个包可能穿插在一起

[rularys]

假如同一时刻只有一个 recv I/O 操作在等待，不会有乱序的问题；
假如同一时刻有一个以上的 recv I/O 操作在等待,则所有正在等待的操作在数据到达时，它们的完成顺序以它们被投递时的顺序为依。两种情况均与线程无关。

情况一：
任何一个线程在处理完成的recv I/O 操作时，在处理完成之前不投递下一个recv I/O ,这能保证同一时刻只有一个 recv I/O 操作在等待。

情况二：

可能同时投递了一个以上的recv I/O,但无论如何，这个“同时”对IOCP来说还是有先后顺序的，IOCP对投递的未完成操作是以先进先出的顺序来满足完成状态的。要避免多个完成的I/O操作返回时无法确认它们的先后顺序，那么在投递I/O时，可以在与I/O关联的数据中填写该I/O的投递顺序号，这样该I/O返回时，就可以根据该顺序号来确定它的完成时间位置。与I/O关联的数据,即 通常所说的单I/O数据。

[Leo_red]

你再往同一个缓存里面写，就接着刚才已经写了的位置写喽，不然从缓冲区的头开始写，不就吧刚才写的东西冲掉了？
这个和粘包处理的方法一样嘛

[mme]

6楼说的没错,关键就是每次只投递一个recv请求

[shenyi0106]

Send---->Recv 不会乱

Send Recv
Send -------> Recv 会乱，你应该加序号，这是你应用层的问题，应该你自己处理
Send Recv

[jy02404957]

多线程处理IO 有必要吗？

[woshisaoge]

[Quote=引用 6 楼 的回复:]

多Thread接收也不会错的

除非你同时，向一个SOCKET 发送2个Recv请求。但是如果出现这种情况你是
应该将后一个Recv排队的等待第一个Recv完成，之后在发送Recv请求
[/Quote]

对于每个客户端连接来说，需要用队列保存吗？

[sorawa]

[Quote=引用 25 楼 的回复:]
我想请问一下，SOCKET中RecvBuf里面它开设有多大，我听说是8192最大？
也是我们现在所做的SOCKET编程的send or recv是从操作系统里面为这个SOCKET开设的BUFFER中以送或接收数据，

是这样理解吗？
[/Quote]

不是这样理解，初始化缓冲区大小需要时间，操作缓冲区也需要时间，而8192 和 4096 权衡性能和缓冲大小都是很合适的。