Socket的阻塞模式和非阻塞模式

阻塞模式

　　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模型”，它有助於應用程式通過非同步方式，同時對一個或多個通訊端的通訊加以管理。

來源:http://blog.csdn.net/VCSockets/