- 浏览: 441160 次
- 性别:
- 来自: 广州
文章分类
- 全部博客 (538)
- C/C++ Primer (69)
- Objective-C Primer (102)
- Python Primer (19)
- JavaScript Primer (1)
- Java Primer (37)
- PHP Primer (17)
- 泛 Linux (37)
- Shell Script (21)
- APUE (21)
- UNP__1&2 (19)
- NetWork (7)
- Oracle周边 (38)
- Mysql里边 (6)
- Windows技 (9)
- 简单算法 & 数据结构 (14)
- 设计模式 (6)
- GTK历程 (12)
- 工具使用 (25)
- 杂事 (23)
- 一些概念 (17)
- Web方面 (10)
- myCodeTools (9)
- ^未 竟$ (13)
- 硬件通信 (2)
- Games (1)
最新评论
copy:http://hi.baidu.com/yaofly/blog/item/a0668b4bf71449f882025c50.html
这文章貌似不错,sorry,习惯用貌似了~
摘要:在应用程序开发中,经常涉及各式各样的机器的交互通信问题。在Windows操作系统下,可以使用MFC中的CSocket,也可以使用以Windows Api为基础的Winsock等等。本文主要描述了Winsock的两种实现方式,即阻塞方式和非阻塞方式。并对应这两种方式,描述了Select模式和IOCP模式。
关键字:Winsock Blocking NonBlocking Select模式 完成端口(IOCP)模式
一、Winsock简介
对于众多底层网络协议,Winsock是访问它们的首选接口。而且在每个Win32平台上,Winsock都以不同的形式存在着。Winsock是网络编程接口,而不是协议。在Win32平台上,Winsock接口最终成为一个真正的“与协议无关”接口,尤其是在Winsock 2发布之后。
Win32平台提供的最有用的特征之一是能够同步支持多种不同的网络协议。Windows重定向器保证将网络请求路由到恰当的协议和子系统;但是,有了Winsock,就可以编写可直接使用任何一种协议的网络应用程序了。
在广泛使用的windows平台下,winsock2被简单包装为一组庞大的Api库,通过WSA Start up加载的关于Winsock版本的信息,初始了winsock相关的dll和lib,在成功调用了WSA Startup之后,即可设计自主的与通信有关的行为,当确认了执行完操作后,调用相应的WSA Cleanup,释放对winsock DLL的引用次数。几乎所有在windows平台下可使用的通信框架都是由Winsock扩展而来的。
这里,之所以要再提windows下的winsock Api编程,并不多余,虽然也可以使用CSocket或ACE(ADAPTIVE Communication Environment)框架,但直接对较底层的本地操作系统API,会使我们更深的理解隐藏在框架下的实现,有时也可以解决一些实用问题。
本文涉及的主要是Winsock中面向连接(TCP)部分。
二、阻塞和非阻塞
阻塞socket,又被称为锁定状态的socket。非阻塞socket,又被称为非锁定状态的socket。当调用一个Winsock Api时, Api的调用会耗费一定的CPU时间。当一个操作完成之后才返回到用户态,称其为阻塞,反之,则为非阻塞。当调用Api产生一个基于流协议(TCP)的socket时,系统开辟了接收和发送两个缓冲区,所以操作实际都是用户缓冲区和系统缓冲区的数据交互,并不是实际操作的完成,阻塞也是如此。如果综合被TCP协议默认使用的nagle算法,在数据包(TCP Payload)比较短时,协议可能推迟其发送,就不难想象了。
很多做过Winsock通信的人,都知道非阻塞的socket,也就是异步socket的效率远远高于阻塞socket。可是除了直观的认识外,底层的原理又是什么呢?首先,阻塞的socket的最合理方式是:先知道socket句柄的可读写性,再发起动作。因为如果不做检测而直接发起操作,那么TCP的默认超时将让你后悔不该这么鲁莽。于是,在一次动作中,完成了两次从用户态到系统态的状态转换,异步的socket实际只告诉系统,所期望的操作,而不完成这种操作,系统会对每次提交的操作进行排队。当指定的操作完成时,系统态跳转至用户态。这样,只用了一次状态转换。其次,由于阻塞的特性,它比非阻塞占用了更多的CPU时间。
当然,程序总是要适合需求,有时阻塞的socket亦可满足要求。
三、Select模式
select模式是Winsock中最常见的I/O模型。之所以称其为“select模式”,是由于它的中心思想是利用select函数,实现对I/O的管理。利用select函数,判断套接字上是否存在数据,或者能否向一个套接字写入数据。设计这个函数,唯一的目的是防止应用程序在套接字处于锁定模式中时,在一次I/O绑定调用(如send或recv)过程中,被迫进入“锁定”状态。
对select不再赘述,msdn已经给出了详细的解释。这里要讨论下面两个问题。
1.Select的fd_set数组可承受的最大数
细心的coder可能都注意到了msdn中对FD_SETSIZE(winsock2.h)宏的说明,可以在包含winsock2.h之前重新定义这个宏,它将允许在一个select操作中处理更多的socket句柄(>64)。但是为何定义就是64呢?这不仅是unix的遗留,更是select处理能力的一种衡量标准,过多的socket句柄检测毕竟会影响到对已存在操作的socket的响应。一个最合理的建议是,当程序运行在多CPU的机器上时,可以从逻辑上将socket句柄分为数个组,每组都小于64,用多个线程对每组socket进行select,这样可以增加程序的响应能力。如果是单CPU,则可将FD_SETSIZE增大至256,适当放大timeout。这时每个socket上吞吐量如果还很大,CPU利用率也据高不下,那就要考虑换种模型。
2.Select在多端口侦听中的应用
众所周知,在winsock api中,accept()是一个典型的阻塞操作,通常是建立一个侦听线程来单独执行accept()。如果程序要完成多于一个端口的侦听,自然,建立数个线程也是一个办法,但这里最好使用select。Msdn中解释了这种应用:readfds可以检测出当前listening的socket句柄上是否有有效的connect发生。把本地listening的socket句柄置入readfds,当某个socket有效时,对它调用accept(),此时,发现accept()会立刻成功返回,一个线程就完成了多端口的侦听。
这文章貌似不错,sorry,习惯用貌似了~
摘要:在应用程序开发中,经常涉及各式各样的机器的交互通信问题。在Windows操作系统下,可以使用MFC中的CSocket,也可以使用以Windows Api为基础的Winsock等等。本文主要描述了Winsock的两种实现方式,即阻塞方式和非阻塞方式。并对应这两种方式,描述了Select模式和IOCP模式。
关键字:Winsock Blocking NonBlocking Select模式 完成端口(IOCP)模式
一、Winsock简介
对于众多底层网络协议,Winsock是访问它们的首选接口。而且在每个Win32平台上,Winsock都以不同的形式存在着。Winsock是网络编程接口,而不是协议。在Win32平台上,Winsock接口最终成为一个真正的“与协议无关”接口,尤其是在Winsock 2发布之后。
Win32平台提供的最有用的特征之一是能够同步支持多种不同的网络协议。Windows重定向器保证将网络请求路由到恰当的协议和子系统;但是,有了Winsock,就可以编写可直接使用任何一种协议的网络应用程序了。
在广泛使用的windows平台下,winsock2被简单包装为一组庞大的Api库,通过WSA Start up加载的关于Winsock版本的信息,初始了winsock相关的dll和lib,在成功调用了WSA Startup之后,即可设计自主的与通信有关的行为,当确认了执行完操作后,调用相应的WSA Cleanup,释放对winsock DLL的引用次数。几乎所有在windows平台下可使用的通信框架都是由Winsock扩展而来的。
这里,之所以要再提windows下的winsock Api编程,并不多余,虽然也可以使用CSocket或ACE(ADAPTIVE Communication Environment)框架,但直接对较底层的本地操作系统API,会使我们更深的理解隐藏在框架下的实现,有时也可以解决一些实用问题。
本文涉及的主要是Winsock中面向连接(TCP)部分。
二、阻塞和非阻塞
阻塞socket,又被称为锁定状态的socket。非阻塞socket,又被称为非锁定状态的socket。当调用一个Winsock Api时, Api的调用会耗费一定的CPU时间。当一个操作完成之后才返回到用户态,称其为阻塞,反之,则为非阻塞。当调用Api产生一个基于流协议(TCP)的socket时,系统开辟了接收和发送两个缓冲区,所以操作实际都是用户缓冲区和系统缓冲区的数据交互,并不是实际操作的完成,阻塞也是如此。如果综合被TCP协议默认使用的nagle算法,在数据包(TCP Payload)比较短时,协议可能推迟其发送,就不难想象了。
很多做过Winsock通信的人,都知道非阻塞的socket,也就是异步socket的效率远远高于阻塞socket。可是除了直观的认识外,底层的原理又是什么呢?首先,阻塞的socket的最合理方式是:先知道socket句柄的可读写性,再发起动作。因为如果不做检测而直接发起操作,那么TCP的默认超时将让你后悔不该这么鲁莽。于是,在一次动作中,完成了两次从用户态到系统态的状态转换,异步的socket实际只告诉系统,所期望的操作,而不完成这种操作,系统会对每次提交的操作进行排队。当指定的操作完成时,系统态跳转至用户态。这样,只用了一次状态转换。其次,由于阻塞的特性,它比非阻塞占用了更多的CPU时间。
当然,程序总是要适合需求,有时阻塞的socket亦可满足要求。
三、Select模式
select模式是Winsock中最常见的I/O模型。之所以称其为“select模式”,是由于它的中心思想是利用select函数,实现对I/O的管理。利用select函数,判断套接字上是否存在数据,或者能否向一个套接字写入数据。设计这个函数,唯一的目的是防止应用程序在套接字处于锁定模式中时,在一次I/O绑定调用(如send或recv)过程中,被迫进入“锁定”状态。
对select不再赘述,msdn已经给出了详细的解释。这里要讨论下面两个问题。
1.Select的fd_set数组可承受的最大数
细心的coder可能都注意到了msdn中对FD_SETSIZE(winsock2.h)宏的说明,可以在包含winsock2.h之前重新定义这个宏,它将允许在一个select操作中处理更多的socket句柄(>64)。但是为何定义就是64呢?这不仅是unix的遗留,更是select处理能力的一种衡量标准,过多的socket句柄检测毕竟会影响到对已存在操作的socket的响应。一个最合理的建议是,当程序运行在多CPU的机器上时,可以从逻辑上将socket句柄分为数个组,每组都小于64,用多个线程对每组socket进行select,这样可以增加程序的响应能力。如果是单CPU,则可将FD_SETSIZE增大至256,适当放大timeout。这时每个socket上吞吐量如果还很大,CPU利用率也据高不下,那就要考虑换种模型。
2.Select在多端口侦听中的应用
众所周知,在winsock api中,accept()是一个典型的阻塞操作,通常是建立一个侦听线程来单独执行accept()。如果程序要完成多于一个端口的侦听,自然,建立数个线程也是一个办法,但这里最好使用select。Msdn中解释了这种应用:readfds可以检测出当前listening的socket句柄上是否有有效的connect发生。把本地listening的socket句柄置入readfds,当某个socket有效时,对它调用accept(),此时,发现accept()会立刻成功返回,一个线程就完成了多端口的侦听。
发表评论
-
UNP_1_Chapter 6__select_pool
2011-04-12 16:57 648http://blog.csdn.net/wbczyh/arc ... -
UNP_1_Chapter 5__TCP_C/S示例
2011-04-01 15:34 604C/S启动时发生什么 C正常结上时发生什么 S在C前终止,C会 ... -
UNP_1_Chapter 4__基本TCP socket编程
2011-04-01 14:40 5874.7 fork与exec close、fork、引用计数器 ... -
unp封装的函数
2011-04-01 10:56 633// 屏蔽IPv4 IPv6 char *sock_n ... -
UNP_1_Chapter 3__基本socket
2011-03-31 18:53 720进程->内核,传递socket地址的函数:bind、co ... -
UNP_1_Chapter 2__TCP、UDP、SCTP
2011-03-31 16:58 6282.10、TCP端口号与并发服务器 服务器,根据端口号区分是否 ... -
UNP_1_Chapter 1__简介
2011-03-31 09:47 698编写计算机网络通信程序,首先要确定相互通信所用的协议(prot ... -
UNP_2_Read Line Function
2010-11-17 11:26 970UNP Code ssize_t Readline(int ... -
UNP_2_Chapter 4
2010-11-16 09:01 523pipe、FIFO、named pipe -
UNP_2_Chapter 1
2010-11-10 15:00 583http://blog.csdn.net/menuconfig ... -
TCP_UDP
2010-10-22 10:52 743A进程用TCP发2个2k的包,接收方用1.5kbuffer ... -
发送邮件相关(1)
2010-09-30 11:43 550http://www.oschina.net/bbs/thre ... -
常用函数
2010-09-29 16:20 1017http://huiya1983.blog.163.com/b ... -
地址互转
2010-08-18 11:11 537http://hi.baidu.com/xiao___q/bl ... -
Libcap & WinPcap
2010-08-04 11:12 1110libpcap是unix/linux平 ... -
单播、组播、广播、组播以及泛洪
2010-07-30 17:29 1049http://www.360doc.com/content/0 ... -
socket IO 幽默解法
2010-07-19 10:59 648http://luckybirdtom.blog.hexun. ... -
BSD Socket概述
2010-03-31 11:24 1252------------------------------- ...
相关推荐
基于Winsock的TCP_IP网络通信
1.应用Visual C++中MFC CSocket类,实现网络数据传输。 2.仿照本实验步骤,制作实用的局域网一对一聊天程序。
winsock多线程阻塞网络通信源码,经典实验
基于Winsock实现聊天程序论文
基于winsock实现的简单聊天室,可以实现多人聊天。
非阻塞模式实现面向连接一个服务器和多个客户端的收发数据(select模型) 阻塞模式实现面向无连接的一对一的通信 1.学习通过winsock编程实现网络通信。 2.学习面向连接和面向无连接的网络通讯方式的编程。 3.学习...
使用winsock虽然比较繁琐,但对于理解异步非阻塞网络通信的概念非常有用。
这个是vb中基于udp的winsock控件应用的通信小程序! 类似于上一个基于tcp的!
基于Winsock通信的远程屏幕抓取技术研究
1、把发送、接收消息转为 Window窗口...2、可以只用一个主线程即负责界面、又负责socket通信,而界面不会卡 3、构建了一个Server可以与多个Client连接的模型。 4、基于VC6.0平台,源作者的源码基于VS2008.非原创,3ks。
基于WINSOCK的网络实时通信系统的实现 基于WINSOCK的网络实时通信系统的实现
基于WinSock的即时通信软件功能原理模拟.doc
这是用WinSock实现C/S通信的程序,由Client发起通信,Server作出相应回响。
利用windows sockets 实现客户端和用户端的TCP方式通信。
源码展示了采用非阻塞模式WinSock编程的服务器和客户端,建立连接后,在服务器窗口输入空格会向所有客户端发送一条字符串消息。 WinSock解决方案下的Client、Server工程分别为服务器和客户端,NetWork工程为稍作封装...
java实现的双机通信,有点类似于简单的QQ程序
用c语言编写的,Winsock实现FTP客户端,实现断点上传和下载,支持pasv和port模式,列出服务器目录内容,改变服务器目录,添加删除目录,删除文件,断开连接。 平台:win7 开发工具:VS2008
主要介绍了详解socket阻塞与非阻塞,同步与异步、I/O模型,socket网络编程中的同步,异步,阻塞式,非阻塞式,有何联系与区别,本文将详细讲诉。
vc异步非阻塞WINSOCK_API经典源代码
基于winsock的聊天室程序,属于网络编程。希望对学网络编程的人有好处。