Socket程式設計中select 的妙用

2021-04-18 15:09:48 字數 3878 閱讀 6573

發信站: 華南網木棉站 (tue aug 4 15:43:41 1998), 轉信 

【 原文由 cpu 所發表 】 

用過 winsock api 網友們知道:winsock 程式設計中有一很方便的地方便是其 

息驅動機制,不管是底層 api 的 wsaasyncselect() 還是 mfc 的非同步socket類: 

casyncsocket,都提供了諸如 fd_accept、fd_read、fd_close 之類的訊息 

供程式設計人員捕捉並處理。fd_accept 通知程序有客戶方socket請求連線, 

fd_read通知程序本地socket有東東可讀,fd_close通知程序對方socket已 

關閉。那麼,bsd socket 是不是真的相形見拙呢? 

非也! 'cause cpu love unix so. 

bsd unix中有一系統呼叫芳名select()完全可以提供類似的訊息驅動機制。 

cpu鄭重宣布:winsock的wsaasyncseclet()不過是此select()的fork版! 

bill也是fork出來的嘛,xixi. 

select()的機制中提供一fd_set的資料結構,實際上是一long型別的陣列, 

每乙個陣列元素都能與一開啟的檔案控制代碼(不管是socket控制代碼,還是其他 

檔案或命名管道或裝置控制代碼)建立聯絡,建立聯絡的工作由程式設計師完成, 

當呼叫select()時,由核心根據io狀態修改fd_set的內容,由此來通知執 

行了select()的程序哪一socket或檔案可讀,下面具體解釋: 

#include 

#include 

#include 

int select(nfds, readfds, writefds, exceptfds, timeout) 

int nfds; 

fd_set *readfds, *writefds, *exceptfds; 

struct timeval *timeout; 

ndfs:select監視的檔案控制代碼數,視程序中開啟的檔案數而定,一般設為呢要監視各檔案 

中的最大檔案號加一。 

readfds:select監視的可讀檔案控制代碼集合。 

writefds: select監視的可寫檔案控制代碼集合。 

exceptfds:select監視的異常檔案控制代碼集合。 

timeout:本次select()的超時結束時間。(見/usr/sys/select.h, 

可精確至百萬分之一秒!) 

當readfds或writefds中映象的檔案可讀或可寫或超時,本次select() 

就結束返回。程式設計師利用一組系統提供的巨集在select()結束時便可判 

斷哪一檔案可讀或可寫。對socket程式設計特別有用的就是readfds。 

fd_zero(fd_set *fdset):清空fdset與所有檔案控制代碼的聯絡。 

fd_set(int fd, fd_set *fdset):建立檔案控制代碼fd與fdset的聯絡。 

fd_clr(int fd, fd_set *fdset):清除檔案控制代碼fd與fdset的聯絡。 

fd_isset(int fd, fdset *fdset):檢查fdset聯絡的檔案控制代碼fd是否 

可讀寫,>0表示可讀寫。 

(關於fd_set及相關巨集的定義見/usr/include/sys/types.h) 

這樣,你的socket只需在有東東讀的時候才讀入,大致如下: 

... 

int      sockfd; 

fd_set fdr; 

struct timeval timeout = ..; 

... 

for(;;)  

} } 

所以乙個fd_isset(sockfd)就相當通知了sockfd可讀。 

至於struct timeval在此的功能,請man select。不同的timeval設定 

使使select()表現出超時結束、無超時阻塞和輪詢三種特性。由於 

timeval可精確至百萬分之一秒,所以windows的settimer()根本不算 

什麼。你可以用select()做乙個超級時鐘。 

fd_accept的實現?依然如上,因為客戶方socket請求連線時,會傳送 

連線請求報文,此時select()當然會結束,fd_isset(sockfd)當然大 

於零,因為有報文可讀嘛!至於這方面的應用,主要在於服務方的父 

socket,你若不喜歡主動accept(),可改為如上機制來accept()。 

至於fd_close的實現及處理,頗費了一堆cpu處理時間,未完待續。 

-- 討論關於利用select()檢測對方socket關閉的問題: 

仍然是本地socket有東東可讀,因為對方socket關閉時,會發乙個關閉連線 

通知報文,會馬上被select()檢測到的。關於tcp的連線(三次握手)和關 

閉(二次握手)機制,敬請參考有關tcp/ip的書籍。 

不知是什麼原因,unix好象沒有提供通知程序關於socket或pipe對方關閉的 

訊號,也可能是cpu所知有限。總之,當對方關閉,一執行recv()或read(), 

馬上回返回-1,此時全域性變數errno的值是115,相應的sys_errlist[errno] 

為"connect refused"(請參考/usr/include/sys/errno.h)。所以,在上 

篇的for(;;)...select()程式塊中,當有東西可讀時,一定要檢查recv()或 

read()的返回值,返回-1時要作出關斷本地socket的處理,否則select()會 

一直認為有東西讀,其結果曾幾令cpu傷心欲斷針腳。不信你可以試試:不檢 

查recv()返回結果,且將收到的東東(實際沒收到)寫至標準輸出... 

在有名管道的程式設計中也有類似問題出現。具體處理詳見拙作:發布乙個有用 

的socket客戶方原碼。 

至於主動寫socket時對方突然關閉的處理則可以簡單地捕捉訊號sigpipe並作 

出相應關斷本地socket等等的處理。sigpipe的解釋是:寫入無讀者方的管道。 

在此不作贅述,請詳man signal。 

以上是cpu在作tcp/ip資料傳輸實驗積累的經驗,若有錯漏,請狂炮擊之。 

唉,昨天在hacker區被一幫孫子轟得差點兒沒短路。ren cpu(奔騰的心) z80 

補充關於select在非同步(非阻塞)connect中的應用,剛開始搞socket程式設計的時候 

我一直都用阻塞式的connect,非阻塞connect的問題是由於當時搞proxy scan 

而提出的呵呵 

通過在網上與網友們的交流及查詢相關faq,總算知道了怎麼解決這一問題.同樣 

用select可以很好地解決這一問題.大致過程是這樣的: 

1.將開啟的socket設為非阻塞的,可以用fcntl(socket, f_setfl, o_ndelay)完 

成(有的系統用fnedlay也可). 

2.發connect呼叫,這時返回-1,但是errno被設為einprogress,意即connect仍舊 

在進行還沒有完成. 

3.將開啟的socket設進被監視的可寫(注意不是可讀)檔案集合用select進行監視, 

如果可寫,用 

getsockopt(socket, sol_socket, so_error, &error, sizeof(int)); 

來得到error的值,如果為零,則connect成功. 

在許多unix版本的proxyscan程式你都可以看到類似的過程,另外在solaris精華 

區->程式設計技巧中有乙個通用的帶超時引數的connect模組.  

socket程式設計中select的使用

select在socket程式設計中還是比較重要的,可是對於初學socket的人來說都不太愛用select寫程式,他們只是習慣寫諸如connect accept recv或recvfrom這樣的阻塞程式 所謂阻塞方式block,顧名思義,就是程序或是執行緒執行到這些函式時必須等待某個事件的發生,如果...

socket程式設計中select的使用

select在socket程式設計中還是比較重要的,可是對於初學socket的人來說都不太愛用select寫程式,他們只是習慣寫諸如connect accept recv或recvfrom這樣的阻塞程式 所謂阻塞方式block,顧名思義,就是程序或是執行緒執行到這些函式時必須等待某個事件的發生,如果...

Socket程式設計中select 的妙用

原文由 cpu 所發表 用過 winsock api 們知道 winsock 程式設計中有一很方便的地方便是其 息驅動機制,不管是底層 api 的 wsaasyncselect 還是 mfc 的非同步socket類 casyncsocket,都提供了諸如 fd accept fd read fd c...