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