99国内精品久久久久久久,久久精品视频91,久久国产高清一区二区三区

setsockopt参数详细说明(转蝲)

yunboy — Wed, 29 Jul 2009 00:33:00 GMT

int setsockopt(
SOCKET s,
int level,
int optname,
const char* optval,
int optlen
);

s(套接�?: 指向一个打开的套接口描述�?
level:(�U�别)�Q?#160;指定选项代码的类型�?
SOL_SOCKET: 基本套接�?#160;
IPPROTO_IP: IPv4套接�?#160;
IPPROTO_IPV6: IPv6套接�?#160;
IPPROTO_TCP: TCP套接�?#160;
optname(选项�?�Q?#160;选项名称
optval(选项�?: 是一个指向变量的指针 �c�d��Q�整形，套接口结构，其他�l�构�c�d��:linger{}, timeval{ }
optlen(选项长度) �Q�optval 的大��?#160;

�q�回��|��标志打开或关闭某个特征的二进刉��项
[/code:1:59df4ce128]

========================================================================
SOL_SOCKET
------------------------------------------------------------------------
SO_BROADCAST 允许发送广播数�?#160;int
适用�?#160;UDP socket。其意义是允�?#160;UDP socket 「广播」（broadcast�Q�讯息到�|��\上�?

SO_DEBUG 允许调试 int

SO_DONTROUTE 不查找�\�?#160;int

SO_ERROR 获得套接字错�?#160;int

SO_KEEPALIVE 保持�q�接 int
��对方主机是否崩溃，避免�Q�服务器�Q�永�q�阻塞于TCP�q�接的输入�?#160;讄��该选项后，如果2��时内在此套接口的�Q一方向都没有数据交换，TCP��p��动给�Ҏ�� 发一个保持存�z�L��分�?keepalive probe)。这是一个对方必��d��应的TCP分节.它会��D��以下三种情况�Q?#160;�Ҏ��接收一切正常：以期望的ACK响应�?��时后，TCP��发出另一个探��分节�?#160;�Ҏ��已崩溃且已重新启动：以RST响应。套接口的待处理错误被置为ECONNRESET�Q�套�?#160;口本�w�则被关闭�?#160;�Ҏ��无�Q何响应：源自berkeley的TCP发送另�?个探��分节，盔R��75�U�一个，试图得到一个响应。在发出�W�一个探��分�?1分钟15�U�后若仍无响应就攑ּ�。套接口的待处理�?#160;误被�|��ؓETIMEOUT�Q�套接口本��n则被关闭。如ICMP错误�?#8220;host unreachable(��L��?#160;可达)”�Q�说明对方主机�ƈ没有崩溃�Q�但是不可达�Q�这�U�情况下待处理错误被�|��ؓ EHOSTUNREACH�?#160;

SO_DONTLINGER 若�ؓ真，则SO_LINGER选项被禁止�?
SO_LINGER 延迟关闭�q�接 struct linger
上面�q�两个选项影响close行�ؓ
选项间隔关闭方式 �{�待关闭与否
SO_DONTLINGER 不关�?#160;优雅 �?
SO_LINGER �?#160;强制 �?
SO_LINGER 非零优雅 �?
若设�|�了SO_LINGER�Q�亦即linger�l�构中的l_onoff域设为非�Ӟ��参见2.4�Q?.1.7�?.1.21各节�Q�，�q�设�|�了零超旉��隔，则closesocket()不被��d��立即执行�Q�不论是否有排队数据未发送或未被��认。这�U�关闭方式称�?#8220;强制”�?#8220;失效”关闭�Q�因为套接口的虚电�\立即被复位，且丢�׃��未发送的数据。在�q�端的recv()调用��以WSAECONNRESET出错�?
若设�|�了SO_LINGER�q�确定了非零的超旉��隔，则closesocket()调用��d��q�程�Q�直到所剩数据发送完毕或��时。这�U�关闭称�?#8220;优雅�?#8221;关闭。请注意如果套接口置为非��d��且SO_LINGER设�ؓ非零��时�Q�则closesocket()调用��以WSAEWOULDBLOCK错误�q�回�?
若在一个流�c�d��接口上设�|�了SO_DONTLINGER�Q�也��是说将linger�l�构的l_onoff域设为零�Q�参�?.4�Q?.1.7�Q?.1.21节）�Q�则closesocket()调用立即�q�回。但是，如果可能�Q�排队的数据��在套接口关闭前发送。请注意�Q�在�q�种情况下WINDOWS套接口实现将在一�D�不��定的时间内保留套接口以及其他资源，�q�对于想用所以套接口的应用程序来说有一定媄响�?

SO_OOBINLINE 带外数据攑օ�正常数据��?在普通数据流中接收带外数�?#160;int

SO_RCVBUF 接收�~�冲区大��?#160;int
讄��接收�~�冲区的保留大小
�?#160;SO_MAX_MSG_SIZE 或TCP滑动�H�口无关�Q�如果一般发送的包很大很频繁�Q�那么��用这个选项

SO_SNDBUF 发送缓冲区大小 int
讄��发送缓冲区的保留大��?
�?#160;SO_MAX_MSG_SIZE 或TCP滑动�H�口无关�Q�如果一般发送的包很大很频繁�Q�那么��用这个选项
每个套接口都有一个发送缓冲区和一个接收缓冲区�?#160;接收�~�冲��TCP和UDP用来��接收到的数据一直保存到由应用进�E�来诅R�?#160;TCP�Q�TCP通告另一端的�H�口大小�?#160;TCP套接口接收缓冲区不可能溢出，因�ؓ�Ҏ��不允许发��q�所通告�H�口大小的数据�?#160;�q�就是TCP的流量控�Ӟ��如果�Ҏ��无视�H�口大小而发��Z��过宙口大小的数据，则接收方TCP��丢弃它�?#160;UDP�Q�当接收到的数据报装不进套接口接收缓冲区�Ӟ��此数据报��p��丢弃。UDP是没�?#160;��量控制的；快的发送者可以很�Ҏ��地就�Ҏ��慢的接收者，��D��接收方的UDP丢弃数据报�?

SO_RCVLOWAT 接收�~�冲��Z��?#160;int
SO_SNDLOWAT 发送缓冲区下限 int
每个套接口都有一个接收低潮限度和一个发送低潮限度。它们是函数selectt使用的，接收低潮限度是让select�q�回“可读”而在套接口接收缓冲区中必��L��的数据总量�?#160;——对于一个TCP或UDP套接口，此值缺省�ؓ1。发送低潮限度是让select�q�回“可写” 而在套接口发送缓冲区中必��L��的可用空间。对于TCP套接口，此值常�~�省�?048�?#160;对于UDP使用低潮限度�Q?#160;�׃��其发送缓冲区中可用空间的字节数是从不变化的，只要 UDP套接口发送缓冲区大小大于套接口的低潮限度�Q�这��L��UDP套接口就��L��可写的�?#160;UDP没有发送缓冲区�Q�只有发送缓冲区的大��?

SO_RCVTIMEO 接收��时 struct timeval
SO_SNDTIMEO 发送超�?#160;struct timeval
SO_REUSERADDR 允许重用本地地址和端�?#160;int
充许�l�定已被使用的地址�Q�或端口��P��Q�可以参考bind的man

SO_EXCLUSIVEADDRUSE
独占模式使用端口,��是不充许和其它�E�序使用SO_REUSEADDR�׃�n的��用某一端口�?
在确定多重绑定��用谁的时候，�Ҏ��一条原则是谁的指定最明确则将包递交�l�谁�Q�而且没有权限之分�Q�也��是说低�U�权限的用户是可以重�l�定在高�U�权限如服务启动的端口上�?�q�是非常重大的一个安全隐�?
如果不想让自��q��序被监听�Q�那么��用这个选项

SO_TYPE 获得套接字类�?#160;int
SO_BSDCOMPAT 与BSD�pȝ��兼容 int

==========================================================================
IPPROTO_IP
--------------------------------------------------------------------------
IP_HDRINCL 在数据包中包含IP首部 int
�q�个选项常用于黑客技术中�Q�隐藏自��q��IP地址

IP_OPTINOS IP首部选项 int
IP_TOS 服务�c�d��
IP_TTL 生存旉�� int

以下IPV4选项用于�l�播
IPv4 选项数据�c�d�� ?#160;�q?
　　IP_ADD_MEMBERSHIP struct ip_mreq 加入到组播组�?
　　IP_ROP_MEMBERSHIP struct ip_mreq 从组播组中退�?
　　IP_MULTICAST_IF struct ip_mreq 指定提交�l�播报文的接�?
　　IP_MULTICAST_TTL u_char 指定提交�l�播报文的TTL
　　IP_MULTICAST_LOOP u_char 使组播报文环路有效或无效
在头文�g中定义了ip_mreq�l�构�Q?
[code:1:63724de67f]
struct ip_mreq {
struct in_addr imr_multiaddr; /* IP multicast address of group */
struct in_addr imr_interface; /* local IP address of interface */
};
[/code:1:63724de67f]
若进�E�要加入��C��个组播组中，用soket的setsockopt()函数发送该选项。该选项�c�d��是ip_mreq�l�构�Q�它的第一个字�D�imr_multiaddr指定了组播组的地址�Q�第二个字段imr_interface指定了接口的IPv4地址�?
　　IP_DROP_MEMBERSHIP
　　该选项用来从某个组播组中退出。数据结构ip_mreq的��用方法与上面相同�?
　　IP_MULTICAST_IF
　　该选项可以修改�|�络接口�Q�在�l�构ip_mreq中定义新的接口�?
　　IP_MULTICAST_TTL
　　讄��l�播报文的数据包的TTL�Q�生存时��_��。默认值是1�Q�表�C�数据包只能在本地的子网中传送�?
　　IP_MULTICAST_LOOP
　　�l�播�l�中的成员自�׃��会收到它向本�l�发送的报文。这个选项用于选择是否�Ȁ�z�这�U�状态�?br>

无双回复于：2003-05-08 21:21:52

IPPRO_TCP
--------------------------------------------------------------------------
TCP_MAXSEG TCP最大数据段的大��?#160;int
获取或设�|�TCP�q�接的最大分节大��?MSS)。返回值是我们的TCP发送给另一端的最�?#160;数据量，它常常就是由另一端用SYN分节通告的MSS�Q�除非我们的TCP选择使用一个比 �Ҏ��通告的MSS��些的倹{��如果此值在套接口连接之前取得，则返回��gؓ未从�?#183;—端收到Mss选项的情况下所用的�~�省倹{��小于此�q�回值的信可能真正用在连接上�Q�因�� 如说使用旉��戳选项的话�Q�它在每个分节上占用12字节的TCP选项定w��。我们的TcP��?#160;发送的每个分节的最大数据量也可在连接存�z�L��内改变，但前提是TCP要支持�\径MTU 发现功能。如果到�Ҏ��的�\径改变了�Q�此值可上下调整�?
TCP_NODELAY 不��用Nagle��法 int

指定TCP开始发送保持存�z�L��分节前以秒为单位的�q�接�I�闲旉��。缺省��D��必��Mؓ7200�U�，�?��时。此选项仅在SO_KEPALIVEE套接口选项打开时才有效�?

TCP_NODELAY �?#160;TCP_CORK�Q?
�q�两个选项都对�|�络�q�接的行为具有重要的作用。许多UNIX�pȝ��都实��C��TCP_NODELAY选项�Q�但是，TCP_CORK则是Linux�pȝ��所独有的而且相对较新�Q�它首先在内核版�?.4上得以实现。此外，其他UNIX�pȝ��版本也有功能�c�M��的选项�Q�值得注意的是�Q�在某种由BSD�z��的系�l�上的TCP_NOPUSH选项其实��是TCP_CORK的一部分具体实现�?
TCP_NODELAY和TCP_CORK基本上控制了包的“Nagle�?#8221;�Q�Nagle化在�q�里的含义是采用Nagle��法把较��的包组装�ؓ更大的��。John Nagle是Nagle��法的发明�h�Q�后者就是用他的名字来命名的�Q�他�?984�q�首�ơ用�q�种�Ҏ��来尝试解决福�Ҏ��车公司的�|�络拥塞问题�Q�欲了解详情请参看IETF RFC 896�Q�。他解决的问题就是所谓的silly window syndrome �Q�中文称“愚蠢�H�口症候群”�Q�具体含义是�Q�因为普遍终端应用程序每产生一�ơ击键操作就会发送一个包�Q�而典型情况下一个包会拥有一个字节的数据载荷以及40个字节长的包��_��于是产生4000%的过载，很轻易地��p��令网�l�发生拥�?�?#160;Nagle化后来成了一�U�标准�ƈ且立卛_��因特�|�上得以实现。它现在已经成�ؓ�~�省配置了，但在我们看来�Q�有些场合下把这一选项��x��也是合乎需要的�?
现在让我们假设某个应用程序发��Z��一个请求，希望发送小块数据。我们可以选择立即发送数据或者等待��生更多的数据然后再一�ơ发送两�U�策略。如果我们马上发送数据，那么交互性的以及客户/服务器型的应用程序将极大地受益。例如，当我们正在发送一个较短的��h��q�且�{�候较大的响应�Ӟ��相关�q�蝲与传输的数据总量相比��׃��比较低，而且�Q�如果请求立卛_��出那么响应时间也会快一些。以上操作可以通过讄��套接字的TCP_NODELAY选项来完成，�q�样��q��用了Nagle��法�?
另外一�U�情况则需要我们等到数据量辑ֈ�最大时才通过�|�络一�ơ发送全部数据，�q�种数据传输方式有益于大量数据的通信性能�Q�典型的应用��是文�g服务器。应用Nagle��法在这�U�情况下��׃��产生问题。但是，如果你正在发送大量数据，你可以设�|�TCP_CORK选项��用Nagle化，其方式正好同TCP_NODELAY相反�Q�TCP_CORK �?#160;TCP_NODELAY 是互相排斥的�Q�。下面就让我们仔�l�分析下其工作原理�?
假设应用�E�序使用sendfile()函数来�{�U�d��量数据。应用协议通常要求发送某些信息来预先解释数据�Q�这些信息其实就是报头内宏V��典型情况下报头很小�Q�而且套接字上讄��了TCP_NODELAY。有报头的包��被立即传输�Q�在某些情况下（取决于内部的包计数器�Q�，因�ؓ�q�个包成功地被对�Ҏ��到后需要请求对方确认。这��P��大量数据的传输就会被推迟而且产生了不必要的网�l�流量交换�?
但是�Q�如果我们在套接字上讄��了TCP_CORK�Q�可以比��Mؓ在管道上插入“塞子”�Q�选项�Q�具有报头的包就会填补大量的数据�Q�所有的数据都根据大��自动地通过包传输出厅R��当数据传输完成�Ӟ��最好取消TCP_CORK 选项讄��l�连�?#8220;拔去塞子”以便��M��部分的��都能发送出厅R��这�?#8220;塞住”�|�络�q�接同等重要�?
总而言之，如果你肯定能一起发送多个数据集合（例如HTTP响应的头和正文）�Q�那么我们徏议你讄��TCP_CORK选项�Q�这样在�q�些数据之间不存在�g�q�。能极大地有益于WWW、FTP以及文�g服务器的性能�Q�同时也��化了你的工作。示例代码如下：

intfd, on = 1;
…
/* 此处是创建套接字�{�操作，��Z��幅的考虑省略*/
…
setsockopt (fd, SOL_TCP, TCP_CORK, &on, sizeof (on)); /* cork */
write (fd, …);
fprintf (fd, …);
sendfile (fd, …);
write (fd, …);
sendfile (fd, …);
…
on = 0;
setsockopt (fd, SOL_TCP, TCP_CORK, &on, sizeof (on)); /* 拔去塞子 */

不幸的是�Q�许多常用的�E�序�q�没有考虑��C��上问题。例如，Eric Allman�~�写的sendmail��没有对其套接字讄��M��选项�?

Apache HTTPD是因特网上最��行的Web服务器，它的所有套接字��都讄��了TCP_NODELAY选项�Q�而且其性能也深受大多数用户的满意。这是�ؓ什么呢�Q�答案就在于实现的差别之上。由BSD衍生的TCP/IP协议栈（值得注意的是FreeBSD�Q�在�q�种状况下的操作��׃��同。当在TCP_NODELAY 模式下提交大量小数据块传输时�Q�大量信息将按照一�ơwrite()函数调用发送一块数据的方式发送出厅R��然而，因�ؓ负责��h��交付��认的记数器是面向字节而非面向包（在Linux上）的，所以引入�g�q�的概率��降低了很多。结果仅仅和全部数据的大��有关系。�?#160;Linux 在第一包到达之后就要求��认�Q�FreeBSD则在�q�行如此操作之前会等待好几百个包�?

在Linux�pȝ��上，TCP_NODELAY的效果同习惯于BSD TCP/IP协议栈的开发者所期望的效果有很大不同�Q�而且在Linux上的Apache性能表现也会更差些。其他在Linux上频�J�采用TCP_NODELAY的应用程序也有同��L��问题�?

TCP_DEFER_ACCEPT

我们首先考虑的第1个选项是TCP_DEFER_ACCEPT�Q�这是Linux�pȝ��上的叫法�Q�其他一些操作系�l�上也有同样的选项但��用不同的名字�Q�。�ؓ了理解TCP_DEFER_ACCEPT选项的具体思想�Q�我们有必要大致阐述一下典型的HTTP客户/服务器交互过�E�。请回想下TCP是如何与传输数据的目标徏立连接的。在�|�络上，在分��ȝ��单元之间传输的信息称为IP包（或IP 数据报）。一个包��L��一个携带服务信息的包头�Q�包头用于内部协议的处理�Q��ƈ且它也可以携带数据负载。服务信息的典型例子��是一套所谓的标志�Q�它把包标记代表TCP/IP协议栈内的特�D�含义，例如收到包的成功��认�{�等。通常�Q�在�l�过“标记”的包里携带负载是完全可能的，但有�Ӟ��内部逻辑�q��TCP/IP协议栈发出只有包头的IP包。这些包�l�常会引发讨厌的�|�络延迟而且�q�增加了�pȝ��的负载，�l�果��D��|�络性能在整体上降低�?
现在服务器创��Z��一个套接字同时�{�待�q�接。TCP/IP式的�q�接�q�程��是所�?#8220;3�ơ握�?#8221;。首先，客户�E�序发送一个设�|�SYN标志而且不带数据负蝲的TCP包（一个SYN包）。服务器则以发出带SYN/ACK标志的数据包�Q�一个SYN/ACK包）作�ؓ刚才收到包的��认响应。客户随后发送一个ACK包确认收��C��W?个包从而结束连接过�E�。在收到客户发来的这个SYN/ACK包之后，服务器会唤醒一个接收进�E�等待数据到达。当3�ơ握手完成后�Q�客��L��序即开始把“有用�?#8221;的数据发送给服务器。通常�Q�一个HTTP��h��的量是很��的而且完全可以装到一个包里。但是，在以上的情况下，臛_��?个包��用来进行双向传输，�q�样��增加了可观的�g�q�时间。此外，你还得注意到�Q�在“有用�?#8221;数据被发送之前，接收方已�l�开始在�{�待信息了�?
��Z��减轻�q�些问题所带来的媄响，Linux�Q�以及其他的一些操作系�l�）在其TCP实现中包括了TCP_DEFER_ACCEPT选项。它们设�|�在侦听套接字的服务器方�Q�该选项命��o内核不等待最后的ACK包而且在第1个真正有数据的包到达才初始化侦听�q�程。在发送SYN/ACK包之后，服务器就会等待客��L��序发送含数据的IP包。现在，只需要在�|�络上传�?个包了，而且�q�显著降低了�q�接建立的�g�q�，对HTTP通信而言��其如此�?
�q�一选项在好些操作系�l�上都有相应的对�{�物。例如，在FreeBSD上，同样的行为可以用以下代码实现�Q?

/* 为明晰�v见，此处略去无关代码 */
struct accept_filter_arg af = { "dataready", "" };
setsockopt(s, SOL_SOCKET, SO_ACCEPTFILTER, &af, sizeof(af));
�q�个特征在FreeBSD上叫�?#8220;接受�q��o�?#8221;�Q�而且��h��多种用法。不�q�，在几乎所有的情况下其效果与TCP_DEFER_ACCEPT是一��L��Q�服务器不等待最后的ACK包而仅仅等待携带数据负载的包。要了解该选项及其寚w��性能Web服务器的重要意义的更多信息请参考Apache文档上的有关内容�?
��HTTP客户/服务器交互而言�Q�有可能需要改变客��L��序的行�ؓ。客��L��序�ؓ什么要发送这�U?#8220;无用�?#8221;ACK包呢�Q�这是因为，TCP协议栈无法知道ACK包的状态。如果采用FTP而非HTTP�Q�那么客��L��序直到接收了FTP服务器提�C�的数据包之后才发送数据。在�q�种情况下，延迟的ACK��导致客�?服务器交互出现�g�q�。�ؓ了确定ACK是否必要�Q�客��L��序必��ȝ��道应用程序协议及其当前状态。这��P��修改客户行�ؓ��成为必要了�?
对Linux客户�E�序来说�Q�我们还可以采用另一个选项�Q�它也被叫做TCP_DEFER_ACCEPT。我们知道，套接字分成两�U�类型，侦听套接字和�q�接套接字，所以它们也各自��h��相应的TCP选项集合。因此，�l�常同时采用的这两类选项却具有同��L��名字也是完全可能的。在�q�接套接字上讄��该选项以后�Q�客户在收到一个SYN/ACK包之后就不再发送ACK包，而是�{�待用户�E�序的下一个发送数据请求；因此�Q�服务器发送的包也��q��应减��了�?

TCP_QUICKACK

��L��因发送无用包而引发�g�q�的另一个方法是使用TCP_QUICKACK选项。这一选项�?#160;TCP_DEFER_ACCEPT不同�Q�它不但能用作管理连接徏立过�E�而且在正常数据传输过�E�期间也可以使用。另外，它能在客�?服务器连接的��M��一方设�|�。如果知道数据不久即��发送，那么推迟ACK包的发送就会派上用场，而且最好在那个携带数据的数据包上设�|�ACK 标志以便把网�l�负载减到最��。当发送方肯定数据��被立即发送（多个包）�Ӟ��TCP_QUICKACK选项可以讄��?。对处于“�q�接”状态下的套接字该选项的缺省值是1�Q�首�ơ��用以后内核将把该选项立即复位�?�Q�这是个一�ơ性的选项�Q��?
在某些情形下�Q�发出ACK包则非常有用。ACK包将��认数据块的接收�Q�而且�Q�当下一块被处理时不至于引入延迟。这�U�数据传输模式对交互�q�程是相当典型的�Q�因为此�c�L��况下用户的输入时��L��法预��。在Linux�pȝ��上这��是�~�省的套接字行�ؓ�?
在上�q�情况下�Q�客��L��序在向服务器发送HTTP��h��Q�而预先就知道��h��包很短所以在�q�接建立之后��应该立卛_��送，�q�可谓HTTP的典型工作方式。既然没有必要发送一个纯�_�的ACK包，所以设�|�TCP_QUICKACK�?以提高性能是完全可能的。在服务器方�Q�这两种选项都只能在侦听套接字上讄��一�ơ。所有的套接字，也就是被接受呼叫间接创徏的套接字则会�l�承原有套接字的所有选项�?
通过TCP_CORK、TCP_DEFER_ACCEPT和TCP_QUICKACK选项的组合，参与每一HTTP交互的数据包数量��被降低到最��的可接受水�q�I��Ҏ��TCP协议的要求和安全斚w��的考虑�Q�。结果不仅是获得更快的数据传输和��h��处理速度而且�q��客户/服务器双向�g�q�实��C��最��化�?

yunboy 2009-07-29 08:33 发表评论

yunboy — Sun, 26 Jul 2009 03:13:00 GMT

1.非阻塞套接字的模�?br>(1)服务器端
    通常socket�q�行后默认�ؓ��d��模式。要调用ioctlsocket函数讄��非阻塞模式�?br>如：

    WSAData Data;
    WSAStartup(MAKEWORD(2, 2), &Data);
    SerSocket = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
    if(INVALID_SOCKET == SerSocket)
        cout<<"Invalid Socket!\n";
    u_long iMode = 1;
    ioctlsocket(SerSocket, FIONBIO, &iMode);

    在接受客��L��h��的线�E�中�Q�若接受成功��p��回客��L��的套接字�Q�否则返回INVALID_SOCKET错误�Q?br>若错误代码�ؓWSAEWOULDBLOCK�Q�说明当前没有客��L��h��?br>如：
//接受客户端请求线�E?/span>
DWORD WINAPI AcceptClientPro(LPVOID LpP)
{
    SOCKADDR_IN ClientAdrr;
    int AddrLen = sizeof(SOCKADDR);
    //非阻塞模�?/span>
    while (!IsConnet)
    {
        ClientSock = accept(SerSocket, (SOCKADDR *)&ClientAdrr, &AddrLen );
        if(INVALID_SOCKET == ClientSock)
        {
            int n = WSAGetLastError();
            //没有客户端请�?/span>
            if(WSAEWOULDBLOCK == n)
            {
                cout<<"没有客户端发��?"<<endl;
                Sleep(1000);
                continue;
            }else
            {
                cout<<"出现错误!"<<endl;
                Sleep(1000);
            }
        }else
        {
            cout<<"已连接客��L��!"<<endl;
            IsConnet = true;
            break;
        }
    }
    return 0;
}

    ��recv函数来说�Q�在��d��模式中，如果没有客户端发送数据过来，�U�程到这里会��d��Q�直到有�?br>据发送过来�ؓ止。在非阻塞模式中�Q�没有客��L��发送数据过来，�q�回SOCKER_ERROR�Q�错误代码�ؓWSAEWOULDBLOCK�?br>如：
//接收数据�U�程
DWORD WINAPI ReceiveDataPro(LPVOID LpP)
{
    while(!IsConnet);        //保证�q�接后再接受数据
    while(1)
    {
        if(IsReadyRecei)        //保证�~�冲区在未处理时不受新来的数据的影响
        {

            int ReceiLen = recv(ClientSock, (char *)&DataPack, sizeof(DataPack), 0);
            if(SOCKET_ERROR == ReceiLen)
            {
                int Err = WSAGetLastError();
                if(WSAEWOULDBLOCK == Err)
                {
                    cout<<"没有收到数据"<<endl;
                    continue;
                }
                else if (WSAENETDOWN == Err ||//客户端关闭了�q�接
                    WSAETIMEDOUT == Err ||
                    WSAECONNRESET == Err )
                {
                    cout<<"服务器关闭了�q�接"<<endl;
                    break;
                }
            }
            if(0 == ReceiLen)        //客户端关闭了�q�接
            {
                cout<<"ReceiLen = 0"<<endl;
                break;
            }
            if(ReceiLen >= sizeof(DataPack))        //成功接收
            {
                cout<<"已收到数据："<<DataPack.buf<<endl;
                IsReadyRecei = false;
                break;
            }
        }
    }
    return 0;
}

(2)客户�?br>    在客��L��的连接请求线�E�中�Q�connect函数会返回SOCKET_ERROR�Q�这�q�不是说明连接失败，具体情况
要看它的WSAGetLastError()�q�回��|��若它三次�q�回SOCKET_ERROR的Error代码依次为WSAEWOULDBLOCK�Q?br>WSAEINVAL�Q�WSAEISCONN�Q�就说明�q�接服务器成功，否则��p�|。但有的时候WSAEINVAL没有出现��有WSAEISCONN
了，所以我�q�是以WSAEISCONN��接完成的标志�Q�但要注意其实在三次�q�回代码中，�W�一�ơ的WSAEWOULDBLOCK
之前的connect操作��成功了�Q�如果没出意外服务器��p��响应了�?br>如：
//�q�接服务器线�E?/span>
DWORD WINAPI ConnetServerPro(LPVOID LpP)
{
    SOCKADDR_IN ServerAddr;
    ServerAddr.sin_family = AF_INET;
    ServerAddr.sin_port = htons(1200);
    ServerAddr.sin_addr.s_addr = inet_addr("192.168.1.100");
    int BlockFlag = 0;
    int InvalFlag = 0;
    while (!IsConnet)
    {
        int nResu = connect(ClientSock, (SOCKADDR *)&ServerAddr, sizeof(SOCKADDR));
        if(SOCKET_ERROR == nResu)
        {
            int n = WSAGetLastError();

            if(WSAEWOULDBLOCK == n )        //不能立即完成
            {
                cout<<"�q�程1!"<<endl;
                BlockFlag++;
                continue;
            }
            else if(WSAEINVAL == n)        //监听状�?/span>
            {
                cout<<"�q�程2!"<<endl;
                InvalFlag++;
                continue;
            }
            else if(WSAEISCONN == n)        //�q�接完成
            {
                cout<<"已连接服务器!"<<endl;
                IsConnet = true;
                break;
            }
            else
            {
                cout<<"出现其他错误!\n"<<endl;
                Sleep(1000);
            }
        }
    }

    return 0;
}

    在发送数据线�E�中�Q�send()�q�回的是发送数据的长度说明发送成功；�q�回SOCKET_ERROR�Ӟ��?br>错误代码为WSAEWOULDBLOCK��再重试�Q�不是WSAEWOULDBLOCK��p��明有错误。�?br>如：
//发送数据线�E?/span>
DWORD WINAPI SendDataPro(LPVOID LpP)
{
    while(!IsConnet);    //保证已连接服务器
    while(1)
    {
        int len = send(ClientSock, (char *)&DataPack, DataPack.Head.len, 0);
        if(SOCKET_ERROR == len)
        {
            int Error = WSAGetLastError();
            if(WSAEWOULDBLOCK == Error)
                continue;
        }
        else        //发送成�?/span>
        {
            cout<<"发送成�?"<<endl;
            break;
        }
    }

    return 0;
}

yunboy 2009-07-26 11:13 发表评论

��d��模式

yunboy — Sun, 26 Jul 2009 03:09:00 GMT

1.��d��模式
    会造成�U�程��d��的有下列四种操作�Q?br>(1) 接受�q�接��h��Q�accept()
(2) 接受数据�Q�recv()�Q�recvfrom()
(3) ��h��q�接�Q�connect()
(4) 发送数据：send()�Q�sendto()
    其中1�?最�Ҏ��发生��d��?br>
2、多�U�程的阻塞模�?br>class CServerDlg : public CDialog
{
    SOCKET m_ClientSock;
    SOCKET m_ServerSock;
    HANDLE m_RecvThread;
    HANDLE m_AcceptThread;
    .
    friend  DWORD WINAPI RecvThreadPro(LPVOID LpP);
    friend  DWORD WINAPI AcceptThreadPro(LPVOID LpP);
};
//创徏�U�程
BOOL CServerDlg::OnInitDialog()
{

    //创徏�U�程
    DWORD ThreadID;
    m_RecvThread = CreateThread(NULL, 0, RecvThreadPro, this, CREATE_SUSPENDED, &ThreadID);
    m_AcceptThread = CreateThread(NULL, 0, AcceptThreadPro, this, CREATE_SUSPENDED, &ThreadID);
    int Count = ResumeThread(m_AcceptThread);

}
//接收数据�U�程
DWORD WINAPI RecvThreadPro(LPVOID LpP)
{
    CServerDlg *pServer = (CServerDlg *)LpP;
    ZeroMemory(buf, 20);
    int nLen = recv(pServer->m_ClientSock, buf, 20, 0);
    if(SOCKET_ERROR == nLen)
        AfxMessageBox("Recv Failed!");
    else
        AfxMessageBox(buf);
    return 0;
}
//接受客户端请求线�E?/span>
DWORD WINAPI AcceptThreadPro(LPVOID LpP)
{
    CServerDlg *pServer = (CServerDlg *)LpP;
    struct sockaddr ClientAddr;
    int len = sizeof(SOCKADDR_IN);
    pServer->m_ClientSock = accept(pServer->m_ServerSock, &ClientAddr, &len);
    if(SOCKET_ERROR == pServer->m_ClientSock)
        AfxMessageBox("Accept Failed!");
    return 0;
}
//�l�束�U�程
void CServerDlg::OnClose()
{
    // TODO: Add your message handler code here and/or call default
    //�l�束AcceptThread
    DWORD ThreadState;
    GetExitCodeThread(m_AcceptThread, &ThreadState);
    if(ThreadState == STILL_ACTIVE)
    {
        //TerminateThread(m_hThread, 0);
        WaitForSingleObject(m_AcceptThread,0xffffffff);
        CloseHandle(m_AcceptThread);
    }
    //�l�束RecvThread
    GetExitCodeThread(m_RecvThread, &ThreadState);
    if(ThreadState == STILL_ACTIVE)
    {
        //TerminateThread(m_RecvThread, 0);
        WaitForSingleObject(m_RecvThread,0xffffffff);
        CloseHandle(m_RecvThread);
    }


    CDialog::OnClose();
}

yunboy 2009-07-26 11:09 发表评论