主服务线程accept,每监听到一个新的连接,就为他创建一个子服务线程,在子服务线程里recv()、send该连接有关的数据。
或者只有一个select线程,同时查看多个fd。有连接就recv/send
这两种做法有啥区别啊?

解决方案 »

  1.   

    第一种做法会导致创建的子线程越来越多,第二种则不会。
    windows下线程创建有数量限制的,这样等于限制了客户端数量。
      

  2.   

    用IOCP,所有fd均绑到一个完成端口上,用工作线程轮询,效率更高
      

  3.   

    IOCP,处理大规模的连接并发请求
      

  4.   

    我需要处理的连接数很少,小于10个。是不是可以理解为,连接数多的时候select效率高。连接数少的时候,为每个连接分别创建一个子服务线程效率高。因为线程的维护也要考虑效率。但其实,recv/send相当于I/O的,所以,能并发尽量并发?只是因为windows线程的限制吗?
      

  5.   

    看你客户端的量,如果只有几个或者10几个链接数的话,当然可以用第一种方法,因为这个简单
    但是如果有几百甚至几千的链接数的话,你不可能开几千个线程啊,这样不现实也严重影响性能所以处理大并发量的话,选择用select或者用iocp
      

  6.   

    不明白为啥select的效率高了?因为select中多个socket的处理在一个线程里,第二个的处理,还要等第一个recv完之后才行。
    而为每个连接创建一个线程,这个在recv等待i/o的时候,另一个线程就可以开始自己用cpu了。
    当然,我指得是线程数量少的情况下
      

  7.   

    第二种比较强大,除了你说的select还可以处理很多事情,比如你说的i/o问题,有些时候像发送文件,还非这样用不可
    具体的可以看一下 unix网络编程关于select的描述,楼主就会明白了
    或者反汇编一下飞鸽传书成win32 asm,基本上你就明白为什么不得不用了
      

  8.   


    这个时候socket是异步的,不需要等recv完成,这个等待可能是由你的网络层去完成,而不是你的CPU
    具体可能要去查看select模式的实现了
      

  9.   

    多核或者多cpu就不是你说的这样了
      

  10.   

    更准确点,是一个processor在一个时刻只能执行一个线程,多核的计算机当时可以同时执行多个线程。select模型可以一个线程处理多个socket,效果比每个socket对应一个线程要高。线程太多时,光在这些线程进行切换就耗费很多CPU时间片,所以IOCP效率高,使用线程池的缘故。
      

  11.   

    注意:select也有fd个数的限制的,可不是无限的。
      

  12.   

    我当然知道一个cpu同时,只能处理一个线程,但我的意思说是,当线程a在处理 i/o这种不浪费cpu资源的操作时,线程b可以利用一下cpu。这样岂不比一个select线程死等recv高。
    楼上有人说的“这个时候socket是异步的,不需要等recv完成,这个等待可能是由你的网络层去完成,而不是你的CPU ”,比如,recv的数据到一个数组里,然后,要处理这个数组。recv不完成,我咋知道这个数组里面的数据能不能用?
    另外,我一开始就说了,线程比较少,因此,不要老揪着iocp不放,我也知道线程切换浪费时间
      

  13.   

    如果只有10个连接,二者的效率区别几乎可以忽略最大的区别是实现方式不同第一种方式相当于accept后,由专门的线程来处理,思路清晰,容易控制,如果对于10个连接的处理方式相同,建议采用这种处理,只写一个客户工作线程,启动多次而已,如果不同的用户,处理方式不同,不要采用这种方法第二种方式 是先fd_set,将多个fd同时select 当有消息时,需要判断每个fd,  FD_ISSET返回TRUE,然后进行accept,recv等操作,不同的fd处理方式不同,应该采用此方式
    recv没有太大区别,只是在服务器send的时候,派发需要较好的控制个人认为第一种方式思路更清晰更好控制
      

  14.   

    第一种方式,是一种per-client-per-Thread方式,实现简单,结构清晰,但是客户端多了后,系统开销大,故只适合很小规模的系统\
    第二种方式,采用的集合的方式来管理socket,可以同时等待几个连接,效率比较高,并且允许的客户端数量也较多,个人觉得实现起来并不复杂,网上,书上资料较多,也是不错的一种选择
      

  15.   

    第一种适合小客户量的情况,第二种用一个线程处理收发, 但是select的socket数量是有限的.理想的情况是 iocp + 线程池.
      

  16.   

    select 模型适合处理事务级别的或是数据量不大的..如果数据量大的话效率速度明显不如多线程的
    多线程对数据量的大的比较适合...
    这样够通俗了把
      

  17.   

    补充两者我在单核.一次查询数据库一万条数据时做的测试..select 需要15秒左右返回 ...多线程在11秒左右返回.测试n次..改进多线程为缓冲队列.4秒返回..