阻塞和非阻塞通信
同步、異步、阻塞和非阻塞是幾種基本的sockets調用方式,也是在進行網絡編程時需要理解和區分的基本概念之一。關于這方面的文章和討論相當豐富,這里著重討論其中兩個比較容易混淆的兩個,即非阻塞與異步的關系。
先還是簡單所列一下幾中調用方式的常見解釋:
同步:函數沒有執行完不返回,線程被掛起;
阻塞:沒有收完數據函數不返回,線程也被掛起;
異步:函數立即返回,通過事件或是信號通知調用者;
非阻塞:函數立即返回,通過select通知調用者
同步和阻塞是比較容易弄明白其含義的,但在實際編程過程中,異步與非阻塞的概念卻并不能直觀地區分于“通過事件或是信號通知調用者”與“通過select通知調用者”這種字面解釋。
?
阻塞通信意味著通信方法在嘗試訪問套接字或者讀寫數據時阻塞了對套接字的訪問。在 JDK 1.4 之前,繞過 阻塞限制的方法是無限制地使用線程,但這樣常常會造成大量的線程開銷,對系統的性能和可伸縮性產生影響。java.nio 包改變了這種狀況,允許服務器有效地使用 I/O 流,在合理的時間內處理所服務的客戶請求。
?
沒有非阻塞通信,這個過程就像我所喜歡說的“為所欲為”那樣。基本上,這個過程就是發送和讀取任何能夠發送/讀取的東西。如果沒有可以讀取的東西,它就中止讀操作,做其他的事情直到能夠讀取為止。當發送數據時,該過程將試圖發送所有的數據,但返回實際發送出的內容。可能是全部數據、部分數據或者根本沒有發送數據。
?
阻塞與非阻塞相比確實有一些優點,特別是遇到錯誤控制問題的時候。在阻塞套接字通信中,如果出現錯誤,該訪問會自動返回標志錯誤的代碼。錯誤可能是由于網絡超時、套接字關閉或者任何類型的 I/O 錯誤造成的。在非阻塞套接字通信中,該方法能夠處理的唯一錯誤是網絡超時。為了檢測使用非阻塞通信的網絡超時,需要編寫稍微多一點的代碼,以確定自從上一次收到數據以來已經多長時間了。
?
哪種方式更好取決于應用程序。如果使用的是同步通信,如果數據不必在讀取任何數據之前處理的話,阻塞通信更好一些,而非阻塞通信則提供了處理任何已經讀取的數據的機會。而異步通信,如 IRC 和聊天客戶機則要求非阻塞通信以避免凍結套接字。
?
Java中的阻塞和非阻塞IO包各自的優劣思考
?
NIO 設計背后的基石:反應器模式,用于事件多路分離和分派的體系結構模式。
反應器(Reactor):用于事件多路分離和分派的體系結構模式
?
通常的,對一個文件描述符指定的文件或設備, 有兩種工作方式: 阻塞 與非阻塞 。所謂阻塞方式的意思是指, 當試圖對該文件描述符進行讀寫時, 如果當時沒有東西可讀,或者暫時不可寫, 程序就進入等待 狀態, 直到有東西可讀或者可寫為止。而對于非阻塞狀態, 如果沒有東西可讀, 或者不可寫, 讀寫函數馬上返回, 而不會等待 。
?
一種常用做法是:每建立一個Socket連接時,同時創建一個新線程對該Socket進行單獨通信(采用阻塞的方式通信)。這種方式具有很高的響應速度,并且控制起來也很簡單,在連接數較少的時候非常有效,但是如果對每一個連接都產生一個線程的無疑是對系統資源的一種浪費,如果連接數較多將會出現資源不足的情況。
?
另一種較高效的做法是:服務器端保存一個Socket連接列表,然后對這個列表進行輪詢,如果發現某個Socket端口上有數據可讀時(讀就緒),則調用該socket連接的相應讀操作;如果發現某個 Socket端口上有數據可寫時(寫就緒),則調用該socket連接的相應寫操作;如果某個端口的Socket連接已經中斷,則調用相應的析構方法關閉該端口。這樣能充分利用服務器資源,效率得到了很大提高。
?
傳統的阻塞式IO,每個連接必須要開一個線程來處理,并且沒處理完線程不能退出。
?
非阻塞式IO,由于基于反應器模式,用于事件多路分離和分派的體系結構模式,所以可以利用線程池來處理。事件來了就處理,處理完了就把線程歸還。而傳統阻塞方式不能使用線程池來處理,假設當前有10000個連接,非阻塞方式可能用1000個線程的線程池就搞定了,而傳統阻塞方式就需要開10000個來處理。如果連接數較多將會出現資源不足的情況。非阻塞的核心優勢就在這里。
?
為什么會這樣,下面就對他們做進一步細致具體的分析:
?
首先,我們來分析傳統阻塞式IO的瓶頸在哪里。在連接數不多的情況下,傳統IO編寫容易方便使用。但是隨著連接數的增多,問題傳統IO就不行了。因為前面說過,傳統IO處理每個連接都要消耗 一個線程,而程序的效率當線程數不多時是隨著線程數的增加而增加,但是到一定的數量之后,是隨著線程數的增加而減少。這里我們得出結論,傳統阻塞式IO的瓶頸在于不能處理過多的連接。
?
然后,非阻塞式IO的出現的目的就是為了解決這個瓶頸。而非阻塞式IO是怎么實現的呢?非阻塞IO處理連接的線程數和連接數沒有聯系,也就是說處理10000個連接非阻塞IO不需要10000個線程,你可以用1000個也可以用2000個線程來處理。因為非阻塞IO處理連接是異步的。當某個連接發送請求到服務器,服務器把這個連接請求當作一個請求"事件",并把這個"事件"分配給相應的函數處理。我們可以把這個處理函數放到線程中去執行,執行完就把線程歸還。這樣一個線程就可以異步的處理多個事件。而阻塞式IO的線程的大部分時間都浪費在等待請求上了。
?
轉載聲明: 本文轉自 http://blog.csdn.net/liuzhengkang/archive/2008/12/20/3562115.aspx
?
===========================================================================
?
非阻塞 Socoket 編程
?
在互聯網相當普及的今天,在互聯網上聊天對很多“網蟲”來說已經是家常便飯了。聊天室程序可以說是網上最簡單的多點通信程序。聊天室的實現方法有很多,但都是利用所謂的“多用戶空間”來對信息進行交換,具有典型的多路I/O的架構。一個簡單的聊天室, 從程序員的觀點來看就是在多個I/O端點之間實現多對多的通信。其架構如圖一所示。這樣的實現在用戶的眼里就是聊天室內任何一個人輸入一段字符之后,其他用戶都可以得到這一句話。這種“多用戶空間”的架構在其他多點通信程序中應用的非常廣泛,其核心就是多路I/O通信。多路I/O通信又被稱為I/O多路復用(I/OMultiplexing)一般被使用在以下的場合:
客戶程序需要同時處理交互式的輸入和同服務器之間的網絡連接時需要處理I/O多路復用問題;
客戶端需要同時對多個網絡連接作出反應(這種情況很少見);
TCP服務器需要同時處理處于監聽狀態和多個連接狀態的socket;
服務器需要處理多個網絡協議的socket;
服務器需要同時處理不同的網絡服務和協議。
聊天室所需要面對的情況正是第一和第三兩種情況。我們將通過在TCP/IP協議之上建立一個功能簡單的聊天室讓大家更加了解多路I/O以及它的實現方法。我們要討論的聊天室功能非常簡單, 感興趣的朋友可以將其功能擴展, 發展成一個功能比較完整的聊天室, 如加上用戶認證, 用戶昵稱, 秘密信息, semote 等功能.
首先它是一個 client/server 結構的程序, 首先啟動 server, 然后用戶使用 client進行連接. client/server 結構的優點是速度快, 缺點是當 server 進行更新時,client 也必需更新.
網絡初始化
首先是初始化 server, 使server 進入監聽狀態: (為了簡潔起見,以下引用的程序與實際程序略有出入, 下同)
sockfd = socket( AF_INET,SOCK_STREAM, 0);
// 首先建立一個 socket, 族為 AF_INET, 類型為 SOCK_STREAM.
// AF_INET = ARPA Internet protocols 即使用 TCP/IP 協議族
// SOCK_STREAM 類型提供了順序的, 可靠的, 基于字節流的全雙工連接.
// 由于該協議族中只有一個協議, 因此第三個參數為 0
bind( sockfd, ( struct sockaddr *)&serv_addr, sizeof( serv_addr));
// 再將這個 socket 與某個地址進行綁定.
// serv_addr 包括 sin_family = AF_INET 協議族同 socket
// sin_addr.s_addr = htonl( INADDR_ANY) server 所接受的所有其他
// 地址請求建立的連接.
// sin_port = htons( SERV_TCP_PORT) server 所監聽的端口
// 在本程序中, server 的 IP和監聽的端口都存放在 config 文件中.
listen( sockfd, MAX_CLIENT);
// 地址綁定之后, server 進入監聽狀態.
// MAX_CLIENT 是可以同時建立連接的 client 總數.
server 進入 listen 狀態后, 等待 client 建立連接。
Client端要建立連接首先也需要初始化連接:
sockfd = socket( AF_INET,SOCK_STREAM,0));
// 同樣的, client 也先建立一個 socket, 其參數與 server 相同.
connect( sockfd, ( struct sockaddr *)&serv_addr, sizeof( serv_addr));
// client 使用 connect 建立一個連接.
// serv_addr 中的變量分別設置為:
// sin_family = AF_INET 協議族同 socket
// sin_addr.s_addr = inet_addr( SERV_HOST_ADDR) 地址為 server
// 所在的計算機的地址.
// sin_port = htons( SERV_TCP_PORT) 端口為 server 監聽的端口.
當 client 建立新連接的請求被送到Server端時, server 使用 accept 來接受該
連接:
accept( sockfd, (struct sockaddr*)&cli_addr, &cli_len);
// 在函數返回時, cli_addr 中保留的是該連接對方的信息
// 包括對方的 IP 地址和對方使用的端口.
// accept 返回一個新的文件描述符.
在 server 進入 listen 狀態之后, 由于已有多個用戶在線,所以程序需要同時對這些用戶進行操作,并在它們之間實現信息交換。這在實現上稱為I/O多路復用技術。多路復用一般有以下幾種方法:
非阻塞通信方法:將文件管道通過fcntl()設為非阻塞通信方式,每隔一端時間對他們實行一次輪詢,以判斷是否可以進行讀寫操作。這種方式的缺點是費用太高,大部分資源浪費在輪詢上。
子進程方法:應用多個子進程,每一個對一個單工阻塞方式通信。所有子進程通過IPC和父進程進行通信。父進程掌管所有信息。這種方式的缺點是實現復雜,而且由于IPC在各個操作系統平臺上并不完全一致,會導致可移植性降低。
信號驅動(SIGIO)的異步I/O方法:首先,異步I/O是基于信號機制的,并不可靠。其次單一的信號不足以提供更多的信息來源。還是需要輔助以其他的手段,實現上有很高的難度。
select ()方法:在BSD中提供了一種可以對多路I/O進行阻塞式查詢的方法——select()。它提供同時對多個I/O描述符進行阻塞式查詢的方法,利用它,我們可以很方便的實現多路復用。根據統一UNIX規范的協議,POSIX也采用了這種方法,因此,我們可以在大多數操作系統中使用select方法。
使用專門的I/O多路復用器:在“UNIX? SYSTEM V Programmer's Guide: STREAMS”一書中詳細的說明了構造和使用多路復用器的方法。這里就不再詳述了。
我們下面分別討論多路I/O的兩種實現方法:
1. 非阻塞通信方法
對一個文件描述符指定的文件或設備, 有兩種工作方式: 阻塞與非阻塞。所謂阻塞方式的意思是指, 當試圖對該文件描述符進行讀寫時, 如果當時沒有東西可讀,或者暫時不可寫, 程序就進入等待狀態, 直到有東西可讀或者可寫為止。而對于非阻塞狀態, 如果沒有東西可讀, 或者不可寫, 讀寫函數馬上返回, 而不會等待。缺省情況下, 文件描述符處于阻塞狀態。在實現聊天室時, server 需要輪流查詢與各client 建立的 socket,一旦可讀就將該 socket 中的字符讀出來并向所有其他client 發送。并且, server 還要隨時查看是否有新的 client 試圖建立連接,這樣, 如果 server 在任何一個地方阻塞了, 其他client 發送的內容就會受到影響,得不到服務器的及時響應。新 client試圖建立連接也會受到影響。所以我們在這里不能使用缺省的阻塞的文件工作方式,而需要將文件的工作方式變成非阻塞方式。在UNIX下,函數fcntl()可以用來改變文件I/O操作的工作方式,函數描述如下:
fcntl( sockfd, F_SETFL, O_NONBLOCK);
// sockfd 是要改變狀態的文件描述符.
// F_SETFL 表明要改變文件描述符的狀態
// O_NONBLOCK 表示將文件描述符變為非阻塞的.
為了節省篇幅我們使用自然語言描述聊天室 server :
while ( 1)
??? if 有新連接 then 建立并記錄該新連接;
??? for ( 所有的有效連接)
??? begin
??????? if 該連接中有字符可讀 then
??????? begin
??????? 讀入字符串;
??????????? for ( 所有其他的有效連接)
??????????? begin
??????????? 將該字符串發送給該連接;
??????????? end;
??????? end;
??? end;
end.
由于判斷是否有新連接, 是否可讀都是非阻塞的, 因此每次判斷,不管有還是沒有, 都會馬上返回. 這樣,任何一個 client 向 server 發送字符或者試圖建立新連接,都不會對其他 client 的活動造成影響。
對 client 而言, 建立連接之后, 只需要處理兩個文件描述符, 一個是建立了連接的socket 描述符, 另一個是標準輸入. 和 server 一樣, 如果使用阻塞方式的話,很容易因為其中一個暫時沒有輸入而影響另外一個的讀入.. 因此將它們都變成非阻塞的,然后client 進行如下動作:
while ( 不想退出)
begin
??? if ( 與 server 的連接有字符可讀)
??? begin
??? 從該連接讀入, 并輸出到標準輸出上去.
??? End;
??? if ( 標準輸入可讀)
??? Begin
??? 從標準輸入讀入, 并輸出到與 server 的連接中去.
??? End;
End.
上面的讀寫分別調用這樣兩個函數:
read( userfd[i], line, MAX_LINE);
// userfd[i] 是指第 i 個 client 連接的文件描述符.
// line 是指讀出的字符存放的位置.
// MAX_LINE 是一次最多讀出的字符數.
// 返回值是實際讀出的字符數.
write( userfd[j], line, strlen( line));
// userfd[j] 是第 j 個 client 的文件描述符.
// line 是要發送的字符串.
// strlen( line) 是要發送的字符串長度.
分析上面的程序可以知道, 不管是 server 還是 client, 它們都不停的輪流查詢各個文件描述符, 一旦可讀就讀入并進行處理. 這樣的程序, 不停的在執行, 只要有CPU 資源, 就不會放過。因此對系統資源的消耗非常大。server 或者 client 單獨執行時,CPU 資源的 98% 左右都被其占用。極大的消耗了系統資源。
select 方法因此,雖然我們不希望在某一個用戶沒有反應時阻塞其他的用戶,但我們卻應該在沒有任何用戶有反應的情況之下停止程序的運行,讓出搶占的系統資源,進入阻塞狀態。有沒有這種方法呢?現在的UNIX系統中都提供了select方法,具體實現方式如下:
select 方法中, 所有文件描述符都是阻塞的. 使用 select 判斷一組文件描述符中是否有一個可讀(寫), 如果沒有就阻塞, 直到有一個的時候就被喚醒. 我們先看比較簡單的 client 的實現:
由于 client 只需要處理兩個文件描述符, 因此, 需要判斷是否有可讀寫的文件描述符只需要加入兩項:
FD_ZERO( sockset);
// 將 sockset 清空
FD_SET( sockfd, sockset);
// 把 sockfd 加入到 sockset 集合中
FD_SET( 0, sockset);
// 把 0 (標準輸入) 加入到 sockset 集合中
然后 client 的處理如下:
while ( 不想退出)
select( sockfd+1, &sockset, NULL, NULL, NULL);
// 此時該函數將阻塞直到標準輸入或者 sockfd 中有一個可讀為止
// 第一個參數是 0 和 sockfd 中的最大值加一
// 第二個參數是 讀集, 也就是 sockset
// 第三, 四個參數是寫集和異常集, 在本程序中都為空
// 第五個參數是超時時間, 即在指定時間內仍沒有可讀, 則出錯
// 并返回. 當這個參數為NULL 時, 超時時間被設置為無限長.
// 當 select 因為可讀返回時, sockset 中包含的只是可讀的
// 那些文件描述符.
if ( FD_ISSET( sockfd, &sockset))
// FD_ISSET 這個宏判斷 sockfd 是否屬于可讀的文件描述符
從 sockfd 中讀入, 輸出到標準輸出上去.
}
if ( FD_ISSET( 0, &sockset))
// FD_ISSET 這個宏判斷 sockfd 是否屬于可讀的文件描述符
從標準輸入讀入, 輸出到 sockfd 中去.
}
重新設置 sockset. (即將 sockset 清空, 并將 sockfd 和 0 加入)
}
下面看 server 的情況:
設置 sockset 如下:
FD_ZERO( sockset);
FD_SET( sockfd, sockset);
for ( 所有有效連接)
FD_SET( userfd[i], sockset);
}
maxfd = 最大的文件描述符號 + 1;
server 處理如下:
while ( 1)
select( maxfd, &sockset, NULL, NULL, NULL);
if ( FD_ISSET( sockfd, &sockset))
// 有新連接
建立新連接, 并將該連接描述符加入到 sockset 中去了.
}
for ( 所有有效連接)
if ( FD_ISSET ( userfd[i], &sockset))
// 該連接中有字符可讀
從該連接中讀入字符, 并發送到其他有效連接中去.
}
}
重新設置 sockset;
}
性能比較
由于采用 select 機制, 因此當沒有字符可讀時, 程序處于阻塞狀態,最小程度的占用CPU 資源, 在同一臺機器上執行一個 server 和若干個client 時, 系統負載只有0.1左右, 而采用原來的非阻塞通信方法, 只運行一個 server, 系統負載就可以達到1.5左右. 因此我們推薦使用 select.
參考文獻:
[1] UNIX Network Programming Volume 1 W.Richard Stevens 1998 Prentice Hall
[2] 計算機實用網絡編程 湯毅堅 1993 人民郵電出版社
[3] UNIX? SYSTEM V RELEASE 4 Programmer's Guide:STREAMS AT&T 1990 Prentice Hall
[4] UNIX? SYSTEM V RELEASE 4 Network Programmer's Guide AT&T 1990 Prentice Hall
所有源程序均登載在eDOC網站上,如有需要可以去http://edoc.163.net下載
轉載聲明: 本文轉自 http://dev.gameres.com/Program/Control/noSocket.htm
?
===========================================================================
轉載于:https://www.cnblogs.com/springside4/archive/2010/09/19/2481764.html
總結
- 上一篇: 老机焕发青春 之硬盘篇
- 下一篇: Svelte 中的 watch: 反应性