关于完成端口中TCP粘包的多线程疑问?

本帖最后由 VisualEleven 于 2011-01-30 09:32:27 编辑

解决方案 »

  1.   

    你如果投递了两个以上的Recv就有可能，你需要自己加包头，然后分析
    如果只投递1一个Recv是不会出现这种问题的
    但是TCP粘包还是要处理，这和协议本身有关
      

  2.   

    你如果投递了两个以上的Recv就有可能，你需要自己加包头，然后分析
    如果只投递1一个Recv是不会出现这种问题的
    但是TCP粘包还是要处理，这和协议本身有关
      

  3.   

    假如包头都被多线程拆分接受了怎么办， 例如我用0xffffeeee来标识包头怎么办。例如现在我是接收到数据WSARecv一次完成后再WSARecv一次，有没有这种可能：我在WSARecv还没完成客户端就发送数据过来了，这个时候应该怎么接受到这个数据呢？完成端口的多线程模型能保证TCP数据的顺序么？
      

  4.   

    TCP本身保证有序的呀，只是您多个线程去取数据就有可能无序了，所以同一时刻只投递一个读取数据就行了，读完成后再去取这样对一个连接来说肯定是有序的了
      

  5.   

    多线程多次recv得到的数据可能因为线程调度问题导致处理的数据包乱序,这时你要处理的话需要自己使用一个后台线程来搞,并且按照次序把它们放入一个缓冲中组成顺序的字节流,再作解析,可以主要的问题就是怎么把多次recv到的数据排出顺序来.具体没这么做过,一般都是单投递发送,接收的.其实效率不能单从这方面考虑,对单个连接也许是这样,但是你应该知道服务器可能是用来服务大量客户端连接的,因此你如果开了4个线程的话,它们都在卖力的为各个连接服务,而不是闲着没事干
      

  6.   

    我的意思是假如服务端这次的WSARecv还没有处理完，而客户端发数据过来了，这种情况下，是否下次的WSARecv会接收到这个数据呢？
      

  7.   

    您数据没有处理完，就不要RECV了，怎么会接到数据呢，您处理完后才RECV后面的，ok?
      

  8.   

    IOCP的优势体现在大规模的异步过程，如果针对每个socket，那你就只需要同时一个RECV，效率并不是在一个socket上体现的，而是整体！
      

  9.   

    唯一的简便方法就是只投递一个recv,其它方法都是浮云
      

  10.   

    一个SOCKET上只投递一个Receive，永远都只投递一个。投递多个Receive基本不会提高效率的。可能楼主没想清楚这个事情，如果真的你的接收程序还需要负责比较耗时的处理，那么问题在于将接收和处理线程分开，而不是投递多个Receive。SOCKET上又不能并行的多个线程同时Receive哦。_____________________________________如果你在一个Receive完成正在处理的时候，Socket上又有数据了，这些数据会等着你下次去Receive的。
      

  11.   

    突然想起来楼主估计没理解完成端口的多个接收线程是什么意思。完成端口的服务器程序，会和很多客户端建立起链接，每个客户端一个SOCKET链接，比如有1000个吧。然后完成端口采用一个线程池，比如包括6个接收线程，专门负责从这1000个SOCKET链接上去Receive数据。每次Receive到的数据包括这个SOCKET的信息和真实接收到的数据，所以我们可以   区分   是那个链接的数据。并且把这个SOCKET链接的数据和上一次这个SOCKET收到的数据一起处理（处理沾包什么的）。
    ——————————————————————————————————————————
    一般不在一个SOCKET上投递多个Receive，如果非要那么做，那么你就要通过TCP的包序号什么的，来进行包的排序工作。
    所以有的书上的代码是包括两部分的：排序，沾包处理
      

  12.   

    http://blog.csdn.net/goodmba/archive/2011/02/10/6177475.aspx   稳定的完成端口开发细节讨论