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操作作好了,你直接拿过来用就行!

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值