Winsock异步----select模型的前前后后

首先看阻塞、非阻塞这两个概念，阻塞是特定的IO函数（象send recv）不会立即返回，在等待返回的这段时间应用程序被阻塞、挂起，IO操作完成之后程序恢复正常；非阻塞不同的情况就是等待IO操作返回时，程序可以做些其他的事情，但这也是比较低效的切换了。

套接字创建时默认是在阻塞模式下的，在这种情况下，一个客户端，即一个连接，就要对应一个线程，服务器连接多少个客户端，就要有多少个线程，客户之间没有影响、干扰；这种方法有一定的灵活性，小规模的通信还不错，缺点也是明显，当连接数量越来越多时，服务器所需要的线程也越来越多，线程消耗大了，而且线程之间的切换同样花费很多时间。系统性能是这种方法的克星，所以开始考虑非阻塞方法。

非阻塞的模式中，IO函数（像send recv）会立即返回，并不代表操作就正确了，大多数情况下，返回的是错误标志---WSAWOULDBLOCK，表明操作没有完成，比如，服务器和客户端工作不协调，一方发出数据，但另一方由于缓冲区满，就不接受，返回该 错误代码；还有，缓冲区没有数据可接收，RECV函数也返回错误代码。主要制约因素就是通信两端没能商量好，一方发起操作，但没有时机，肯定失败结束。非阻塞解决的问题只是 用少量的线程，完成操多的操作。

考虑异步IO模型来提高通信效率，最简单轻巧的就是select 模型，应用程序利用SELECT函数来监视看有哪些可发起的操作，SELECT返回后就可以判断出是否 有时机进行IO操作了，详细过程在另一篇文章里，上传资源也有例子。SELECT实现了少量线程完成大量的操作的机会，也没有错误代码返回。是个很好用的模型。它的内理在于，select包办了等待返回的这个过程，（原来钓鱼时靠自己，不论是一直在河边等，还是暂时离开做其他事 不时的回来查看情况，都没前途，现在有了另一个人SELECT过来帮忙，不论你离不离开忙其他的，他都给你看着），个人觉得SELECT 还是属于同步阻塞型的，它给应用程序发出信号，应用程序就来准备发起操作（比如接受数据或准备发送），但就是这点，IO操作还得应用程序来忙，SELECT最多就是信号员了，那么规模大了，效率还不是最十全十美的。

更高效的异步IO模型高明的地方就是这一点了，不光等信号，还把IO操作作好了，你直接拿过来用就行！