几千用户并发连接到服务器，服务器如何轮询socket？？？

pksun

几千个用户并发连接到服务器，服务器怎么监听socket，知道哪一个用户有数据发送？

采用循环检测socket id的方式，是不是不好？几千次循环才能循环到一次，延时比较严重吧
一个连接起一个线程，似乎也不可能。

有什么好的解决办法？

FH

著名的select

chenys

可以采用poll机制

mep

使用select有著名的文件描述符个数限制，
它不能同时处理大于1024个文件描述符（除去进程打开的文件，stdout/stdin/stderr，剩下1000个左右；在windows NT系列上是64个）。
一般，为了提高服务器的及时响应能力，建议多线程。
可以采用的模型有如下几种（轮询没有讨论）：
1、select
2、采用单独一个线程处理接收和发送或两个线程分别处理接收和发送；
   至于如何处理请求，又有不同的策略选择：
a、每请求一个线程；
b、单个线程顺序处理请求；
c、使用线程池；
d、每客户端一个线程；

选择1、2和a、b、c组合使用，会有不同的效果。
使用select效率最高，不过可能有1024个文件描述符的限制，使得同时链接到服务器的客户端数目受限。多线程的模型由于需要同步，效率比单个线程的要低；但多线程模型的服务器能够及时响应客户端的请求。而对于每请求启动一个线程的模型来说，开销较大，适合于服务器和客户端相互嵌套调用的情况。而没客户端一个线程的模型可能会对特定客户端的响应不够及时，适合客户端数目较固定的情况。线程池模型是一个折中方案；既没有创建线程的开销，又不会有很多的资源闲置。多线程模型在处理请求时，可能需要在请求处理代码中同步。
总之，根据自己的实际需求、实现难度情况进行选择。

zhxlanjuan

在solaris上有/dev/poll机制，在Linux上也有类似的机制。用这种机制进行的多路复用效率比较高，要比poll和select好

hh942111

不是select有1024文件描述符限制！而是经典的select实现在处理大量文件描述符时效率低！mep老兄指的是进程的文件描述符限制，这个在现代的操作系统上都可以通过配置修改了，其实除了多线程，采用多进程select的模型也不错，实现起来要容易些！效率也不错，现代操作系统对select的这个弊端都有所改进，比如solaris就在底层使用poll实现的select！另外可以参考ACE，它优化了select的使用

mep

select文件描述符的问题不是指进程的打开文件个数限制。由于select使用了一个固定大小的数组，
导致不能处理任意多个文件描述符。这和OS没有关系，和编译器以及头文件的定义有关系。

mep

1. 
   
2. #ifndef FD_SETSIZE
   
3. #define FD_SETSIZE      64
   
4. #endif /* FD_SETSIZE */
   
5. 
   
6. typedef struct fd_set {
   
7.         u_int fd_count;               /* how many are SET? */
   
8.         SOCKET  fd_array[FD_SETSIZE];   /* an array of SOCKETs */
   
9. } fd_set;
   

复制代码

以上是VC 6中使用的fd_set定义，有64个的限制。

rockins

[quote]原帖由 "hh942111"]不是select有1024文件描述符限制！而是经典的select实现在处理大量文件描述符时效率低！mep老兄指的是进程的文件描述符限制，这个在现代的操作系统上都可以通过配置修改了，其实除了多线程，采用多进程select的模型?.........[/quote 发表：


我觉得并发用户多达几千个这种情况可能用多进程要容易实现一些,但资源消耗又相对比多线程严重,故楼主需要找一个两者之间的折中才好.据说web服务器采用了很多技术把每一个并发进程的资源消耗降到最低,楼主可以找一下这方面的资料,具体的情形我也不是很清楚.楼主自求多福吧.

yulc

这个问题值得关注，留名一下。