來源:http://blog.csdn.net/VCSockets/
阻塞模式
Windows套接字在阻塞和非阻塞兩種模式下執(zhí)行I/O操作。在阻塞模式下，在I/O操作完成前，執(zhí)行的操作函數(shù)一直等候而不會立即返回，該函數(shù)所在的線程會阻塞在這里。相反，在非阻塞模式下，套接字函數(shù)會立即返回，而不管I/O是否完成，該函數(shù)所在的線程會繼續(xù)運行。
在阻塞模式的套接字上，調(diào)用任何一個Windows Sockets API都會耗費不確定的等待時間。圖所示，在調(diào)用recv()函數(shù)時，發(fā)生在內(nèi)核中等待數(shù)據(jù)和復(fù)制數(shù)據(jù)的過程。
當調(diào)用recv()函數(shù)時，系統(tǒng)首先查是否有準備好的數(shù)據(jù)。如果數(shù)據(jù)沒有準備好，那么系統(tǒng)就處于等待狀態(tài)。當數(shù)據(jù)準備好后，將數(shù)據(jù)從系統(tǒng)緩沖區(qū)復(fù)制到用戶空間，然后該函數(shù)返回。在套接應(yīng)用程序中，當調(diào)用recv()函數(shù)時，未必用戶空間就已經(jīng)存在數(shù)據(jù)，那么此時recv()函數(shù)就會處于等待狀態(tài)。
Windows套接字程序使用“生產(chǎn)者-消費者”模式來解決上述問題。在程序中，“生產(chǎn)者”讀入數(shù)據(jù)，“消費者”根據(jù)需求對讀入數(shù)據(jù)進行處理。通常“生產(chǎn)者”和“消費者”存在于兩個線程中，當“生產(chǎn)者”完成讀入數(shù)據(jù)時，使用線程同步機制，例如設(shè)置一個事件通知“消費者”，“消費者”接收到這個事件后對讀入的數(shù)據(jù)進行處理。
當使用socket()函數(shù)和WSASocket()函數(shù)創(chuàng)建套接字時，默認的套接字都是阻塞的。這意味著當調(diào)用Windows Sockets API不能立即完成時，線程處于等待狀態(tài)，直到操作完成。
并不是所有Windows Sockets API以阻塞套接字為參數(shù)調(diào)用都會發(fā)生阻塞。例如，以阻塞模式的套接字為參數(shù)調(diào)用bind()、listen()函數(shù)時，函數(shù)會立即返回。將可能阻塞套接字的Windows Sockets API調(diào)用分為以下四種:
1．輸入操作
recv()、recvfrom()、WSARecv()和WSARecvfrom()函數(shù)。以阻塞套接字為參數(shù)調(diào)用該函數(shù)接收數(shù)據(jù)。如果此時套接字緩沖區(qū)內(nèi)沒有數(shù)據(jù)可讀，則調(diào)用線程在數(shù)據(jù)到來前一直睡眠。
2．輸出操作
send()、sendto()、WSASend()和WSASendto()函數(shù)。以阻塞套接字為參數(shù)調(diào)用該函數(shù)發(fā)送數(shù)據(jù)。如果套接字緩沖區(qū)沒有可用空間，線程會一直睡眠，直到有空間。
3．接受連接
accept()和WSAAcept()函數(shù)。以阻塞套接字為參數(shù)調(diào)用該函數(shù)，等待接受對方的連接請求。如果此時沒有連接請求，線程就會進入睡眠狀態(tài)。
4．外出連接
connect()和WSAConnect()函數(shù)。對于TCP連接，客戶端以阻塞套接字為參數(shù)，調(diào)用該函數(shù)向服務(wù)器發(fā)起連接。該函數(shù)在收到服務(wù)器的應(yīng)答前，不會返回。這意味著TCP連接總會等待至少到服務(wù)器的一次往返時間。
使用阻塞模式的套接字，開發(fā)網(wǎng)絡(luò)程序比較簡單，容易實現(xiàn)。當希望能夠立即發(fā)送和接收數(shù)據(jù)，且處理的套接字數(shù)量比較少的情況下，使用阻塞模式來開發(fā)網(wǎng)絡(luò)程序比較合適。
阻塞模式套接字的不足表現(xiàn)為，在大量建立好的套接字線程之間進行通信時比較困難。當使用“生產(chǎn)者-消費者”模型開發(fā)網(wǎng)絡(luò)程序時，為每個套接字都分別分配一個讀線程、一個處理數(shù)據(jù)線程和一個用于同步的事件，那么這樣無疑加大系統(tǒng)的開銷。其最大的缺點是當希望同時處理大量套接字時，將無從下手，其擴展性很差。
非阻塞模式
把套接字設(shè)置為非阻塞模式，即通知系統(tǒng)內(nèi)核：在調(diào)用Windows Sockets API時，不要讓線程睡眠，而應(yīng)該讓函數(shù)立即返回。在返回時，該函數(shù)返回一個錯誤代碼。圖所示，一個非阻塞模式套接字多次調(diào)用recv()函數(shù)的過程。前三次調(diào)用recv()函數(shù)時，內(nèi)核數(shù)據(jù)還沒有準備好。因此，該函數(shù)立即返回WSAEWOULDBLOCK錯誤代碼。第四次調(diào)用recv()函數(shù)時，數(shù)據(jù)已經(jīng)準備好，被復(fù)制到應(yīng)用程序的緩沖區(qū)中，recv()函數(shù)返回成功指示，應(yīng)用程序開始處理數(shù)據(jù)。
當使用socket()函數(shù)和WSASocket()函數(shù)創(chuàng)建套接字時，默認都是阻塞的。在創(chuàng)建套接字之后，通過調(diào)用ioctlsocket()函數(shù)，將該套接字設(shè)置為非阻塞模式。Linux下的函數(shù)是:fcntl().
套接字設(shè)置為非阻塞模式后，在調(diào)用Windows Sockets API函數(shù)時，調(diào)用函數(shù)會立即返回。大多數(shù)情況下，這些函數(shù)調(diào)用都會調(diào)用“失敗”，并返回WSAEWOULDBLOCK錯誤代碼。說明請求的操作在調(diào)用期間內(nèi)沒有時間完成。通常，應(yīng)用程序需要重復(fù)調(diào)用該函數(shù)，直到獲得成功返回代碼。
需要說明的是并非所有的Windows Sockets API在非阻塞模式下調(diào)用，都會返回WSAEWOULDBLOCK錯誤。例如，以非阻塞模式的套接字為參數(shù)調(diào)用bind()函數(shù)時，就不會返回該錯誤代碼。當然，在調(diào)用WSAStartup()函數(shù)時更不會返回該錯誤代碼，因為該函數(shù)是應(yīng)用程序第一調(diào)用的函數(shù)，當然不會返回這樣的錯誤代碼。
要將套接字設(shè)置為非阻塞模式，除了使用ioctlsocket()函數(shù)之外，還可以使用WSAAsyncselect()和WSAEventselect()函數(shù)。當調(diào)用該函數(shù)時，套接字會自動地設(shè)置為非阻塞方式。
由于使用非阻塞套接字在調(diào)用函數(shù)時，會經(jīng)常返回WSAEWOULDBLOCK錯誤。所以在任何時候，都應(yīng)仔細檢查返回代碼并作好對“失敗”的準備。應(yīng)用程序連續(xù)不斷地調(diào)用這個函數(shù)，直到它返回成功指示為止。上面的程序清單中，在While循環(huán)體內(nèi)不斷地調(diào)用recv()函數(shù)，以讀入1024個字節(jié)的數(shù)據(jù)。這種做法很浪費系統(tǒng)資源。
要完成這樣的操作，有人使用MSG_PEEK標志調(diào)用recv()函數(shù)查看緩沖區(qū)中是否有數(shù)據(jù)可讀。同樣，這種方法也不好。因為該做法對系統(tǒng)造成的開銷是很大的，并且應(yīng)用程序至少要調(diào)用recv()函數(shù)兩次，才能實際地讀入數(shù)據(jù)。較好的做法是，使用套接字的“I/O模型”來判斷非阻塞套接字是否可讀可寫。
非阻塞模式套接字與阻塞模式套接字相比，不容易使用。使用非阻塞模式套接字，需要編寫更多的代碼，以便在每個Windows Sockets API函數(shù)調(diào)用中，對收到的WSAEWOULDBLOCK錯誤進行處理。因此，非阻塞套接字便顯得有些難于使用。
但是，非阻塞套接字在控制建立的多個連接，在數(shù)據(jù)的收發(fā)量不均，時間不定時，明顯具有優(yōu)勢。這種套接字在使用上存在一定難度，但只要排除了這些困難，它在功能上還是非常強大的。通常情況下，可考慮使用套接字的“I/O模型”，它有助于應(yīng)用程序通過異步方式，同時對一個或多個套接字的通信加以管理。