如何监控socket的变化
如何通知socket的变化
1.select :
应用场合:主要面向的是某些使用U n i x操作系统的计算机,它们采用的是B e r k e l e y套接字方案。s e l e c t模型已集成到Winsock 1.1中,它使那些想避免在套接字调用过程中被无辜“锁定”的应用程序,采取一种有序的方式,同时进行对多个套接字的管理.
原理: 利用select函数,我们判断套接字上是否存在数据,或者能否向一个套接字写入数据.
2.WSAAsyncSelect :
应用场合:用于帮助应用程序开发者面向一些早期的16位Windows平台(如WindowsforWorkgroups),适应其“落后”的多任务消息环境。应用程序仍可从这种模型中得到好处,特别是它们用一个标准的Windows例程(常称为“winproc”),对窗口消息进行管理的时候。该模型亦得到了MicrosoftFoundationClass微软基本类,MFC)对象CSocket的采纳,
原理:利用WSAAsyncSelect来处理FD_READ、FD_WRITE、FD_ACCEPT、FD_CONNECT、FD_CLOSE消息
3 WSAEventSelect:
应用场合: 各种异步Socket 程序. WSAWaitForMultipleEvents 限制最多只能等待64个Event .
原理: 将socket的各种变化通过Event来通知 区别WSAAsyncSelect 窗口消息来通知
4.OverlappedI/O:
应用场合: 与WSAEventSelect模式类似
原理: 将socket的各种变化通过Event来通知 并多了一个绑定的event处理过程.
5.Completionport:
应用场合: 完成端口”模型是迄今为止最为复杂的一种I / O模型。然而,假若一个应用程序同时需要管理为数众多的套接字,那么采用这种模型,往往可以达到最佳的系统性能!但不幸的是,该模型只适用于Windows NT和Windows 2000操作系统。因其设计的复杂性,只有在你的应用程序需要同时管理数百乃至上千个套接字的时候,而且希望随着系统内安装的C P U数量的增多,应用程序的性
能也可以线性提升,才应考虑采用“完成端口”模型
原理: 完成端口模型要求我们创建一个Wi n 3 2完成端口对象,通过指定数量的线程,对重叠I / O请求进行管理,以便为已经完成的重叠I / O请求提供服务
下面是我的一些理解,不知道是否正确,请指教。
综合几种I/O模式,我认为两种模式来实现服务器端的程序是比较好的,一个是最简单的阻塞模式,一个是IOCP。
说简单的阻塞模式好,是因为它实现简单,通常情况下最与服务器来说,是一个主线程用来accept用户的连接,用户连接来之后,单独的启动一个工作线程为其服务,那么可以在工作线程里按照顺序对接收到的数据进行处理,因此实现起来逻辑关系清晰,除了注意一些多线程的安全性,比较容易理解。问题是,当遇到大量的并发连接的时候,大量线程对资源的占用难以为继,因此一般需要多用户的服务器通常会选择其他的模式。
那么要说性能好,可扩展,那就一定是IOCP。从实现的复杂度来说,IOCP也并不是其他几种模式里最复杂的。IOCP里面的数据乱序问题大概是需要注意的地方,再有就是要注意多线程的安全性。
select模式,应该主要是为了与*nix和早期的win3.1系统兼容而使用的,每个处理都要先经过select,性能很难理想
WSAAsyncSelect模式,由于有每线程64object的限制,而且使用窗口的消息机制,也不会有很好的性能
WSAEventSelect,同样的具有64 event的问题。
那么后面的这几个模式到底应该什么情况下使用呢,是不是用IOCP搭建一个优质的框架,以后很多的服务器都可以复用了呢?