socket阻塞模式和非阻塞模式

阻塞模式

　　Windows套接字在阻塞和非阻塞两种模式下执行I/O操作。在阻塞模式下&＃xff0c;在I/O操作完成前&＃xff0c;执行的操作函数一直等候而不会立即返回&＃xff0c;该函数所在的线程会阻塞在这里。相反&＃xff0c;在非阻塞模式下&＃xff0c;套接字函数会立即返回&＃xff0c;而不管I/O是否完成&＃xff0c;该函数所在的线程会继续运行。

在阻塞模式的套接字上&＃xff0c;调用任何一个Windows Sockets API都会耗费不确定的等待时间。图所示&＃xff0c;在调用recv()函数时&＃xff0c;发生在内核中等待数据和复制数据的过程。

当调用recv()函数时&＃xff0c;系统首先查是否有准备好的数据。如果数据没有准备好&＃xff0c;那么系统就处于等待状态。当数据准备好后&＃xff0c;将数据从系统缓冲区复制到用户空间&＃xff0c;然后该函数返回。在套接应用程序中&＃xff0c;当调用recv()函数时&＃xff0c;未必用户空间就已经存在数据&＃xff0c;那么此时recv()函数就会处于等待状态。

    Windows套接字程序使用“生产者-消费者”模式来解决上述问题。在程序中&＃xff0c;“生产者”读入数据&＃xff0c;“消费者”根据需求对读入数据进行处理。通常“生产者”和“消费者”存在于两个线程中&＃xff0c;当“生产者”完成读入数据时&＃xff0c;使用线程同步机制&＃xff0c;例如设置一个事件通知“消费者”&＃xff0c;“消费者”接收到这个事件后对读入的数据进行处理。

　　当使用socket()函数和WSASocket()函数创建套接字时&＃xff0c;默认的套接字都是阻塞的。这意味着当调用Windows Sockets API不能立即完成时&＃xff0c;线程处于等待状态&＃xff0c;直到操作完成。

并不是所有Windows Sockets API以阻塞套接字为参数调用都会发生阻塞。例如&＃xff0c;以阻塞模式的套接字为参数调用bind()、listen()函数时&＃xff0c;函数会立即返回。将可能阻塞套接字的Windows Sockets API调用分为以下四种:

1&＃xff0e;输入操作

recv()、recvfrom()、WSARecv()和WSARecvfrom()函数。以阻塞套接字为参数调用该函数接收数据。如果此时套接字缓冲区内没有数据可读&＃xff0c;则调用线程在数据到来前一直睡眠。

2&＃xff0e;输出操作

send()、sendto()、WSASend()和WSASendto()函数。以阻塞套接字为参数调用该函数发送数据。如果套接字缓冲区没有可用空间&＃xff0c;线程会一直睡眠&＃xff0c;直到有空间。

3&＃xff0e;接受连接

accept()和WSAAcept()函数。以阻塞套接字为参数调用该函数&＃xff0c;等待接受对方的连接请求。如果此时没有连接请求&＃xff0c;线程就会进入睡眠状态。

4&＃xff0e;外出连接

connect()和WSAConnect()函数。对于TCP连接&＃xff0c;客户端以阻塞套接字为参数&＃xff0c;调用该函数向服务器发起连接。该函数在收到服务器的应答前&＃xff0c;不会返回。这意味着TCP连接总会等待至少到服务器的一次往返时间。

　　使用阻塞模式的套接字&＃xff0c;开发网络程序比较简单&＃xff0c;容易实现。当希望能够立即发送和接收数据&＃xff0c;且处理的套接字数量比较少的情况下&＃xff0c;使用阻塞模式来开发网络程序比较合适。

阻塞模式套接字的不足表现为&＃xff0c;在大量建立好的套接字线程之间进行通信时比较困难。当使用“生产者-消费者”模型开发网络程序时&＃xff0c;为每个套接字都分别分配一个读线程、一个处理数据线程和一个用于同步的事件&＃xff0c;那么这样无疑加大系统的开销。其最大的缺点是当希望同时处理大量套接字时&＃xff0c;将无从下手&＃xff0c;其扩展性很差。

非阻塞模式
  把套接字设置为非阻塞模式&＃xff0c;即通知系统内核&＃xff1a;在调用Windows Sockets API时&＃xff0c;不要让线程睡眠&＃xff0c;而应该让函数立即返回。在返回时&＃xff0c;该函数返回一个错误代码。图所示&＃xff0c;一个非阻塞模式套接字多次调用recv()函数的过程。前三次调用recv()函数时&＃xff0c;内核数据还没有准备好。因此&＃xff0c;该函数立即返回WSAEWOULDBLOCK错误代码。第四次调用recv()函数时&＃xff0c;数据已经准备好&＃xff0c;被复制到应用程序的缓冲区中&＃xff0c;recv()函数返回成功指示&＃xff0c;应用程序开始处理数据。

　　当使用socket()函数和WSASocket()函数创建套接字时&＃xff0c;默认都是阻塞的。在创建套接字之后&＃xff0c;通过调用ioctlsocket()函数&＃xff0c;将该套接字设置为非阻塞模式。Linux下的函数是:fcntl().
    套接字设置为非阻塞模式后&＃xff0c;在调用Windows Sockets API函数时&＃xff0c;调用函数会立即返回。大多数情况下&＃xff0c;这些函数调用都会调用“失败”&＃xff0c;并返回WSAEWOULDBLOCK错误代码。说明请求的操作在调用期间内没有时间完成。通常&＃xff0c;应用程序需要重复调用该函数&＃xff0c;直到获得成功返回代码。

    需要说明的是并非所有的Windows Sockets API在非阻塞模式下调用&＃xff0c;都会返回WSAEWOULDBLOCK错误。例如&＃xff0c;以非阻塞模式的套接字为参数调用bind()函数时&＃xff0c;就不会返回该错误代码。当然&＃xff0c;在调用WSAStartup()函数时更不会返回该错误代码&＃xff0c;因为该函数是应用程序第一调用的函数&＃xff0c;当然不会返回这样的错误代码。

    要将套接字设置为非阻塞模式&＃xff0c;除了使用ioctlsocket()函数之外&＃xff0c;还可以使用WSAAsyncselect()和WSAEventselect()函数。当调用该函数时&＃xff0c;套接字会自动地设置为非阻塞方式。

　　由于使用非阻塞套接字在调用函数时&＃xff0c;会经常返回WSAEWOULDBLOCK错误。所以在任何时候&＃xff0c;都应仔细检查返回代码并作好对“失败”的准备。应用程序连续不断地调用这个函数&＃xff0c;直到它返回成功指示为止。上面的程序清单中&＃xff0c;在While循环体内不断地调用recv()函数&＃xff0c;以读入1024个字节的数据。这种做法很浪费系统资源。

    要完成这样的操作&＃xff0c;有人使用MSG_PEEK标志调用recv()函数查看缓冲区中是否有数据可读。同样&＃xff0c;这种方法也不好。因为该做法对系统造成的开销是很大的&＃xff0c;并且应用程序至少要调用recv()函数两次&＃xff0c;才能实际地读入数据。较好的做法是&＃xff0c;使用套接字的“I/O模型”来判断非阻塞套接字是否可读可写。

    非阻塞模式套接字与阻塞模式套接字相比&＃xff0c;不容易使用。使用非阻塞模式套接字&＃xff0c;需要编写更多的代码&＃xff0c;以便在每个Windows Sockets API函数调用中&＃xff0c;对收到的WSAEWOULDBLOCK错误进行处理。因此&＃xff0c;非阻塞套接字便显得有些难于使用。

    但是&＃xff0c;非阻塞套接字在控制建立的多个连接&＃xff0c;在数据的收发量不均&＃xff0c;时间不定时&＃xff0c;明显具有优势。这种套接字在使用上存在一定难度&＃xff0c;但只要排除了这些困难&＃xff0c;它在功能上还是非常强大的。通常情况下&＃xff0c;可考虑使用套接字的“I/O模型”&＃xff0c;它有助于应用程序通过异步方式&＃xff0c;同时对一个或多个套接字的通信加以管理。

转:http://blog.csdn.net/VCSockets/