从打地鼠游戏来看Winsock的Select模型

从打地鼠游戏来看Winsock的Select模型

对于学习过C/S网络编程的读者来说，对Select模型一定不会陌生。Select模型是Winsock中的5种I/O模型之一，它主要用来实现TCP的一对多通信（即一个服务器端程序同时和多个客户端程序进行通信）。实现TCP一对多通信的方法很多，最原始的办法是采用多线程技术，在服务器端同时开启很多个线程，每个线程分别与一个客户端进行通信。这种方法的缺陷是连接的客户端不能太多，如果客户端过多，就会导致服务器端线程数量过多，使服务器端的内存资源耗尽。

那么是否可以让服务器端在一个线程中同时和很多个客户端进行通信呢？答案是可以的，其中的一种方法就是使用select模型。

为了实现一对多通信，select模型在服务器端管理着一个套接字集合FD_SET，这个集合中有很多个套接字，分为通信套接字和监听套接字。每个通信套接字都可以与一个客户端单独进行通信。当套接字集合中的某个通信套接字收到一个事件时，select函数会返回一个值，此时就可以用程序对该事件进行处理，例如，如果是接收到数据的事件，就用recv()函数去接收数据。如果是请求连接的事件，则使用accept()函数去接受连接。因此程序需要时刻监视select模型是否有值返回，这说明select模型是阻塞的，就像打地鼠游戏一样，游戏者需要时刻监视是否有地鼠冒出头来。

打地鼠游戏机的台面上有很多只地鼠，因此可看成是一个地鼠的集合。如果把地鼠看成套接字，那么地鼠伸出头来就对应套接字有可读事件。而打地鼠则对应去处理可读事件。

1. 相似点
   • 地鼠→ 套接字
   • 地鼠伸出头来→ 套接字有可读事件
   • 打地鼠→ 处理套接字的可读消息
2. 区别：
   • select模型的套接字是逐渐加入到套接字集合中的，而打地鼠游戏中的所有地鼠一开始就存在。
   • 套接字集合中有两种套接字，对两种套接字的事件有不同的处理方式，而打地鼠游戏中只有一种地鼠，对所有地鼠伸出头来的处理方式一样。

另外需要注意的是：在普通的TCP通信程序中（未使用Winsock I/O模型），服务器端的accept函数是先于客户端的connect函数执行，即服务器执行accept函数陷入阻塞，等待客户端执行connect函数发送连接请求。

而在select模型中，客户端的connect函数先于服务器端的accept函数执行，因为客户端先发送连接请求，服务器端select函数获取到请求连接的事件，再让监听套接字调用accept函数接受连接。

摘自《TCP/IP网络编程项目式教程》