Socket程式設計中select()的妙用
阿新 • • 發佈:2019-01-29
【 原文由 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 <sys/types.h>
#include <sys/times.h>
#include <sys/select.h>
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_ZERO(&fdR);
FD_SET(sockfd, &fdR);
switch (select(sockfd + 1, &fdR, NULL, &timeout)) {
case -1:
error handled by u;
case 0:
timeout hanled by u;
default:
if (FD_ISSET(sockfd)) {
now u read or recv something;
/* if sockfd is father and
server socket, u can now
accept() */
}
}
}
所以一個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模組.
(http://www.fanqiang.com)
用過 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 <sys/types.h>
#include <sys/times.h>
#include <sys/select.h>
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_ZERO(&fdR);
FD_SET(sockfd, &fdR);
switch (select(sockfd + 1, &fdR, NULL, &timeout)) {
case -1:
error handled by u;
case 0:
timeout hanled by u;
default:
if (FD_ISSET(sockfd)) {
now u read or recv something;
/* if sockfd is father and
server socket, u can now
accept() */
}
}
}
所以一個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模組.
(http://www.fanqiang.com)