|
select()的機制中提供一fd_set的數(shù)據(jù)結構,，實際上是一long類型的數(shù)組,， 每一個數(shù)組元素都能與一打開的文件句柄（不管是Socket句柄,還是其他 文件或命名管道或設備句柄）建立聯(lián)系,，建立聯(lián)系的工作由程序員完成， 當調用select()時,，由內(nèi)核根據(jù)IO狀態(tài)修改fd_set的內(nèi)容，由此來通知執(zhí) 行了select()的進程哪一Socket或文件可讀,，下面具體解釋： #include #include #include int select(nfds, readfds, writefds, exceptfds, timeout) int nfds; fd_set *readfds, *writefds, *exceptfds; struct timeval *timeout; ndfs：select監(jiān)視的文件句柄數(shù),，視進程中打開的文件數(shù)而定,一般設為呢要監(jiān)視各文件 中的最大文件號加一,。 readfds：select監(jiān)視的可讀文件句柄集合。 writefds: select監(jiān)視的可寫文件句柄集合,。 exceptfds：select監(jiān)視的異常文件句柄集合,。 timeout：本次select()的超時結束時間。（見/usr/sys/select.h,， 可精確至百萬分之一秒?。? 當readfds或writefds中映象的文件可讀或可寫或超時，本次select() 就結束返回,。程序員利用一組系統(tǒng)提供的宏在select()結束時便可判 斷哪一文件可讀或可寫,。對Socket編程特別有用的就是readfds。 幾只相關的宏解釋如下： FD_ZERO(fd_set *fdset)：清空fdset與所有文件句柄的聯(lián)系,。 FD_SET(int fd, fd_set *fdset)：建立文件句柄fd與fdset的聯(lián)系,。 FD_CLR(int fd, fd_set *fdset)：清除文件句柄fd與fdset的聯(lián)系。 FD_ISSET(int fd, fdset *fdset)：檢查fdset聯(lián)系的文件句柄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()表現(xiàn)出超時結束,、無超時阻塞和輪詢?nèi)N特性。由于 timeval可精確至百萬分之一秒,，所以Windows的SetTimer()根本不算 什么,。你可以用select()做一個超級時鐘。 FD_ACCEPT的實現(xiàn),？依然如上,，因為客戶方socket請求連接時，會發(fā)送 連接請求報文,，此時select()當然會結束,，F(xiàn)D_ISSET(sockfd)當然大 于零，因為有報文可讀嘛,！至于這方面的應用,，主要在于服務方的父 Socket，你若不喜歡主動accept(),，可改為如上機制來accept(),。 至于FD_CLOSE的實現(xiàn)及處理，頗費了一堆cpu處理時間,，未完待續(xù),。 -- 討論關于利用select()檢測對方Socket關閉的問題： 仍然是本地Socket有東東可讀,，因為對方Socket關閉時，會發(fā)一個關閉連接 通知報文,，會馬上被select()檢測到的,。關于TCP的連接（三次握手）和關 閉（二次握手）機制，敬請參考有關TCP/IP的書籍,。 不知是什么原因,，UNIX好象沒有提供通知進程關于Socket或Pipe對方關閉的 信號，也可能是cpu所知有限,?？傊攲Ψ疥P閉,，一執(zhí)行recv()或read(),， 馬上回返回-1，此時全局變量errno的值是115,，相應的sys_errlist[errno] 為"Connect refused"（請參考/usr/include/sys/errno.h）,。所以，在上 篇的for(;;)...select()程序塊中,，當有東西可讀時,，一定要檢查recv()或 read()的返回值，返回-1時要作出關斷本地Socket的處理,，否則select()會 一直認為有東西讀,，其結果曾幾令cpu傷心欲斷針腳。不信你可以試試：不檢 查recv()返回結果,，且將收到的東東（實際沒收到）寫至標準輸出... 在有名管道的編程中也有類似問題出現(xiàn),。具體處理詳見拙作：發(fā)布一個有用 的Socket客戶方原碼。 至于主動寫Socket時對方突然關閉的處理則可以簡單地捕捉信號SIGPIPE并作 出相應關斷本地Socket等等的處理,。SIGPIPE的解釋是：寫入無讀者方的管道,。 在此不作贅述，請詳man signal,。 以上是cpu在作tcp/ip數(shù)據(jù)傳輸實驗積累的經(jīng)驗,，若有錯漏，請狂炮擊之,。 唉，昨天在hacker區(qū)被一幫孫子轟得差點兒沒短路,。ren cpu(奔騰的心) z80 補充關于select在異步(非阻塞)connect中的應用,剛開始搞socket編程的時候 我一直都用阻塞式的connect,非阻塞connect的問題是由于當時搞proxy scan 而提出的呵呵 通過在網(wǎng)上與網(wǎng)友們的交流及查找相關FAQ,總算知道了怎么解決這一問題.同樣 用select可以很好地解決這一問題.大致過程是這樣的: 1.將打開的socket設為非阻塞的,可以用fcntl(socket, F_SETFL, O_NDELAY)完 成(有的系統(tǒng)用FNEDLAY也可). 2.發(fā)connect調用,這時返回-1,但是errno被設為EINPROGRESS,意即connect仍舊 在進行還沒有完成. 3.將打開的socket設進被監(jiān)視的可寫(注意不是可讀)文件集合用select進行監(jiān)視, 如果可寫,用 getsockopt(socket, SOL_SOCKET, SO_ERROR, &error, sizeof(int)); 來得到error的值,如果為零,則connect成功. Linux下用select查詢串口數(shù)據(jù) Linux下直接用read讀串口可能會造成堵塞,，或數(shù)據(jù)讀出錯誤。然而用select先查詢com口,，再用read去讀就可以避免,，并且當com口延時時,，程序可以退出，這樣就不至于由于com口堵塞,，程序就死了,。我的代碼如下： bool ReadDevice( int hComm, unsigned long uLen, char* pData ) { int nread = 0; char inbuf[uLen]; char buff[uLen]; memset( inbuff, '\0', uLen ); memset( buff, '\0', uLen ); fd_set readset; struct timeval tv; int MaxFd = 0; int c = 0; int z; do { FD_ZERO( &readset ); if( hComm >= 0 ) FD_SET( hComm, &readset ); MaxFd = hComm + 1; tv.tv_sec = 0; tv.tv_usec = 500000; do { z = select( MaxFd, &readset, 0, 0, &tv); }while( z==-1 && errno==EINTR ); if( z == -1 ) printf("select(2)\n"); if( z == 0 ) { hComm = -1; } if( hComm>=0 && FD_ISSET(hComm, &readset) ) { z = read( hComm, buff, uLen - c ); c += z; if( z == -1 ) { hComm = -1; } if( z > 0 ) { buff[ z + 1 ] = '\0'; strcat( inbuff, buff ); memset( buff, 0x00, uLen ); } else { hComm = -1; } } }while( hComm >= 0 ); memcpy( pData, inbuff, c ); return true; } |
|
|
來自： android之情殤 > 《android》
