windows网络模型学习--WINDOWS和LINUX开发模型比较

windows网络模型学习--WINDOWS和LINUX开发模型比较

以前在做LINUX网络开发时把用户层和系统的内核看成两个层面，看简单点就是用户层才能最简单，高效的取到数据；而内核层就是个终端的对象，可以从终端的被动转向主动。

那么在进行网络I/O操作时有这么几种套路来传递数据：
1。普通的recv,send.首先是用户亲自调用函数进到内核I/O空间查看是否有数据，根据是否有数据做出不同的选择。比如有数据则取回，无数据则等待(阻塞模式下)。这是最原始，也是最理想的取数据状态。在单纯的数据连续传递，并且没有多并发情况下算是很高效的。如果没有什么交互或者高连接要求，用这种普通的写法即可。

2。普通套接字的阻塞和非阻塞时间上的判断要不是有数据，要不就立即返回。有时候需要交互的情况，一些缓冲时间，并且可以对多个套接字的控制。就出现了select/poll.即，在我们调用select时，在指定的时间内，内核会告诉我们是否可读取。

3。select的缺陷就是在套接字多的时候，并且不是每个套接字都在活动状态，耗费在了轮询问的状态上。新的改进即，在有数据时，让内核来通知用户层可以读取了。

4。针对第三的变种有：除了信号通知，还可以为内核直接提供存储空间，顺手把数据给装上；或者再变种点，再挂个回调函数，连收到数据处理后的事也一起干完。

针对第4点，LINUX好象没有分开提供这种变种模式，而是直接把回调的这种模式放在EPOLL里实现了。而WINDOWS则分别提供(linux有没提供可能这里我说得不是特别对)

针对这些模式，来看看WINDOWS

参考帖子：
http://topic.csdn.net/u/20080702/20/43466EA1-0F44-4B07-ACFD-7431A1969C20.html

一：select模型
二：WSAAsyncSelect模型 跟第3点类似，但是在量多的时候内核就很繁忙了。
三：WSAEventSelect模型 在第3点上加以改进，为每个套接字都增加一个线程处理。
四：Overlapped I/O 事件通知模型 相对第4点的变种,顺手把数据给装上。
五：Overlapped I/O 完成例程模型 相对第4点变种，不但数据装上,连函数一起调用了。
六：IOCP模型


讨论到这里，所说的端口模型几乎可以解决所有的I/O状况。比如连接量多和少，数据量的频繁。但是第5点的策略是对每个连接分别建个线程进行处理。一种极端的情况可以这样预料，假设有几万个用户，并且其中活跃数不多。那么就有两个问题需要考虑：这些线程的切换效率？活跃用户的轮询时的命中率？

于是就有了最终模型(从目前来看)Windows:IOCP--Linux:EPOLL

如果事先开好N个线程，让它们在那hold[堵塞]，然后可以将所有用户的请求都投递到一个消息队列中去。然后那N个线程逐一从消息队列中去取出消息并加以处理。就可以避免针对每一个用户请求都开线程。不仅减少了线程的资源，也提高了线程的利用率。理论上很不错，你想我等泛泛之辈都能想出来的问题，Microsoft又怎会没有考虑到呢?"-----摘自nonocast的《理解I/O Completion Port》