阻塞的套接字與非阻塞的套接字

阻塞模式

Windows套接字在阻塞和非阻塞兩種模式下執行I/O操做。在阻塞模式下，在I/O操做完成前，執行的操做函數一直等候而不會當即返回，該 函數所在的線程會阻塞在這裏。相反，在非阻塞模式下，套接字函數會當即返回，而無論I/O是否完成，該函數所在的線程會繼續運行。

在阻塞模式的套接字上，調用任何一個Windows Sockets API都會耗費不肯定的等待時間。圖所示，在調用recv()函數時，發生在內核中等待數據和複製數據的過程。

當調用recv()函數時，系統首先查是否有準備好的數據。若是數據沒有準備好，那麼系統就處於等待狀態。當數據準備好後，將數據從系統緩衝區複製 到用戶空間，而後該函數返回。在套接應用程序中，當調用recv()函數時，未必用戶空間就已經存在數據，那麼此時recv()函數就會處於等待狀態。

    Windows套接字程序使用「生產者-消費者」模式來解決上述問題。在程序中，「生產者」讀入數據，「消費者」根據需求對讀入數據進行處理。一般「生產 者」和「消費者」存在於兩個線程中，當「生產者」完成讀入數據時，使用線程同步機制，例如設置一個事件通知「消費者」，「消費者」接收到這個事件後對讀入 的數據進行處理。

當使用socket()函數和WSASocket()函數建立套接字時，默認的套接字都是阻塞的。這意味着當調用Windows Sockets API不能當即完成時，線程處於等待狀態，直到操做完成。

並非全部Windows Sockets API以阻塞套接字爲參數調用都會發生阻塞。例如，以阻塞模式的套接字爲參數調用bind()、listen()函數時，函數會當即返回。將可能阻塞套接字的Windows Sockets API調用分爲如下四種:

1．輸入操做

recv()、recvfrom()、WSARecv()和WSARecvfrom()函數。以阻塞套接字爲參數調用該函數接收數據。若是此時套接字緩衝區內沒有數據可讀，則調用線程在數據到來前一直睡眠。

2．輸出操做

send()、sendto()、WSASend()和WSASendto()函數。以阻塞套接字爲參數調用該函數發送數據。若是套接字緩衝區沒有可用空間，線程會一直睡眠，直到有空間。

3．接受鏈接

accept()和WSAAcept()函數。以阻塞套接字爲參數調用該函數，等待接受對方的鏈接請求。若是此時沒有鏈接請求，線程就會進入睡眠狀態。

4．外出鏈接

connect()和WSAConnect()函數。對於TCP鏈接，客戶端以阻塞套接字爲參數，調用該函數向服務器發起鏈接。該函數在收到服務器的應答前，不會返回。這意味着TCP鏈接總會等待至少到服務器的一次往返時間。

使用阻塞模式的套接字，開發網絡程序比較簡單，容易實現。當但願可以當即發送和接收數據，且處理的套接字數量比較少的狀況下，使用阻塞模式來開發網絡程序比較合適。

阻塞模式套接字的不足表現爲，在大量創建好的套接字線程之間進行通訊時比較困難。當使用「生產者-消費者」模型開發網絡程序時，爲每一個套接字都分別 分配一個讀線程、一個處理數據線程和一個用於同步的事件，那麼這樣無疑加大系統的開銷。其最大的缺點是當但願同時處理大量套接字時，將無從下手，其擴展性 不好。

 

 

 

 

非阻塞模式

  把套接字設置爲非阻塞模式，即通知系統內核：在調用Windows Sockets API時，不要讓線程睡眠，而應該讓函數當即返回。在返回時，該函數返回一個錯誤代碼。圖所示，一個非阻塞模式套接字屢次調用recv()函數的過程。前 三次調用recv()函數時，內核數據尚未準備好。所以，該函數當即返回WSAEWOULDBLOCK錯誤代碼。第四次調用recv()函數時，數據已 經準備好，被複制到應用程序的緩衝區中，recv()函數返回成功指示，應用程序開始處理數據。

當使用socket()函數和WSASocket()函數建立套接字時，默認都是阻塞的。在建立套接字以後，經過調用ioctlsocket()函數，將該套接字設置爲非阻塞模式。Linux下的函數是:fcntl().

    套接字設置爲非阻塞模式後，在調用Windows Sockets API函數時，調用函數會當即返回。大多數狀況下，這些函數調用都會調用「失敗」，並返回WSAEWOULDBLOCK錯誤代碼。說明請求的操做在調用期 間內沒有時間完成。一般，應用程序須要重複調用該函數，直到得到成功返回代碼。

    須要說明的是並不是全部的Windows Sockets API在非阻塞模式下調用，都會返回WSAEWOULDBLOCK錯誤。例如，以非阻塞模式的套接字爲參數調用bind()函數時，就不會返回該錯誤代 碼。固然，在調用WSAStartup()函數時更不會返回該錯誤代碼，由於該函數是應用程序第一調用的函數，固然不會返回這樣的錯誤代碼。

    要將套接字設置爲非阻塞模式，除了使用ioctlsocket()函數以外，還可使用WSAAsyncselect()和WSAEventselect()函數。當調用該函數時，套接字會自動地設置爲非阻塞方式。

因爲使用非阻塞套接字在調用函數時，會常常返回WSAEWOULDBLOCK錯誤。因此在任什麼時候候，都應仔細檢查返回代碼並做好對「失敗」的準 備。應用程序接二連三地調用這個函數，直到它返回成功指示爲止。上面的程序清單中，在While循環體內不斷地調用recv()函數，以讀入1024個字 節的數據。這種作法很浪費系統資源。

    要完成這樣的操做，有人使用MSG_PEEK標誌調用recv()函數查看緩衝區中是否有數據可讀。一樣，這種方法也很差。由於該作法對系統形成的開銷是 很大的，而且應用程序至少要調用recv()函數兩次，才能實際地讀入數據。較好的作法是，使用套接字的「I/O模型」來判斷非阻塞套接字是否可讀可寫。

    非阻塞模式套接字與阻塞模式套接字相比，不容易使用。使用非阻塞模式套接字，須要編寫更多的代碼，以便在每一個Windows Sockets API函數調用中，對收到的WSAEWOULDBLOCK錯誤進行處理。所以，非阻塞套接字便顯得有些難於使用。

    可是，非阻塞套接字在控制創建的多個鏈接，在數據的收發量不均，時間不定時，明顯具備優點。這種套接字在使用上存在必定難度，但只要排除了這些困難，它在 功能上仍是很是強大的。一般狀況下，可考慮使用套接字的「I/O模型」，它有助於應用程序經過異步方式，同時對一個或多個套接字的通訊加以管理。