这段时间一直在IOCP 和 SELECT上做选择。下定决心用IOCP。IOCP显然是很高效的,但在异步下也能体现这种高效呢。我的思路如下
1:IOCP线程负责消息的接收,然后把消息写入BUFF 这个BUFF对应的是连接,处理合包
2:逻辑线程 读取这个线程下管理的连接的BUFF 依次处理逻辑在这个过程中 主要是对 BUFF的读写锁  这个会占用多少资源不知道。。只想到这个方案大家有好的方案吗
我开始想的是 没有逻辑线程 直接在IOCP线程里处理逻辑 感觉这样不好如果逻辑处理比较费时 就容易堵塞住高手给点建议啊。。有没有做过的

解决方案 »

  1.   

    我之前做的就是有几个线程利用IOCP接收并将缓冲区放入消息列队,然后有几个逻辑线程处理接收到的缓冲区,然后还需要针对每一个已连接对象建立一个有顺序的列队,当逻辑线程收到了数据后依照编号将其插入该列队,如果该列队头是要读取的数据包就依次处理所有能够处理的包。
    这里面IOCP接收线程,逻辑线程甚至消息列队的数量都可以根据需求动态调整。
    不过我当时的负载不大,杀鸡用了牛刀,所以也没有测试究竟能有多少吞吐量
      

  2.   


    IOCP负责网络数据的收发,把数据接收到缓冲区去之后,由专门的消息队列去分发消息,专门的数据处理线程去处理数据。
    其中的消息队列机制也可以用IOCP模型来实现。
      

  3.   


    如果是怕阻塞才不在IO线程中处理逻辑,那完全没有必要,逻辑处理放到另一线程中,延迟更严重,因为IO线程收到的数据需要加入队列,这个队列则需要加锁,然后逻辑线程取出消息时还要加开锁,再加上如果处理时间长,客户端一样会延迟。
    我说的只是理论,但实际上,这些锁对整个系统来说不会有太大的影响。而大多数把逻辑线程与IO线程分开的做法,主要是考虑到程序的条理清晰。
      

  4.   

    那数据发送是怎么处理的 另起一个线程做发送。。还是直接投递到IOCP处理还是
      

  5.   

    http://blog.csdn.net/qq752923276/article/details/7674732
      

  6.   

    楼主的想法是对的,接收线程和逻辑处理线程要区分,两者刚好形成消费者模式
    对于buff的同步机制,可以采用临界区(critical_section),
    这个消耗的资源和处理效率,还是可以接受的