• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            loop_in_codes

            低調做技術__歡迎移步我的獨立博客 codemaro.com 微博 kevinlynx

            select真的有限制嗎

            在剛開始學習網絡編程時,似乎莫名其妙地就會被某人/某資料告訴select函數是有fd(file descriptor)數量限制的。在最近的一次記憶里還有個人笑說select只支持64個fd。我甚至還寫過一篇不負責任甚至錯誤的博客(突破select的FD_SETSIZE限制)。有人說,直接重新定義FD_SETSIZE就可以突破這個select的限制,也有人說除了重定義這個宏之外還的重新編譯內核。

            事實具體是怎樣的?實際上,造成這些混亂的原因恰好是不同平臺對select的實現不一樣。

            Windows的實現

            MSDN.aspx)上對select的說明:

            int select(
              _In_     int nfds,
              _Inout_  fd_set *readfds,
              _Inout_  fd_set *writefds,
              _Inout_  fd_set *exceptfds,
              _In_     const struct timeval *timeout
            );
            
            nfds [in] Ignored. The nfds parameter is included only for compatibility with Berkeley sockets.
            

            第一個參數MSDN只說沒有使用,其存在僅僅是為了保持與Berkeley Socket的兼容。

            The variable FD_SETSIZE determines the maximum number of descriptors in a set. (The default value of FD_SETSIZE is 64, which can be modified by defining FD_SETSIZE to another value before including Winsock2.h.) Internally, socket handles in an fd_set structure are not represented as bit flags as in Berkeley Unix.

            Windows上select的實現不同于Berkeley Unix,后者使用位標志來表示socket。

            在MSDN的評論中有人提到:

            Unlike the Linux versions of these macros which use a single calculation to set/check the fd, the Winsock versions use a loop which goes through the entire set of fds each time you call FD_SET or FD_ISSET (check out winsock2.h and you’ll see). So you might want to consider an alternative if you have thousands of sockets!

            不同于Linux下處理fd_set的那些宏(FD_CLR/FD_SET之類),Windows上這些宏的實現都使用了一個循環,看看這些宏的大致實現(Winsock2.h):

            #define FD_SET(fd, set) do { \
                u_int __i; \
                for (__i = 0; __i < ((fd_set FAR *)(set))->fd_count; __i++) { \
                    if (((fd_set FAR *)(set))->fd_array[__i] == (fd)) { \
                        break; \
                    } \
                } \
                if (__i == ((fd_set FAR *)(set))->fd_count) { \
                    if (((fd_set FAR *)(set))->fd_count < FD_SETSIZE) { \
                        ((fd_set FAR *)(set))->fd_array[__i] = (fd); \
                        ((fd_set FAR *)(set))->fd_count++; \
                    } \
                } \
            } while(0)
            

            看下Winsock2.h中關于fd_set的定義:

            typedef struct fd_set {
                u_int fd_count;
                SOCKET fd_array[FD_SETSIZE];
            } fd_set;
            

            再看一篇更重要的MSDN Maximum Number of Sockets Supported.aspx):

            The Microsoft Winsock provider limits the maximum number of sockets supported only by available memory on the local computer. The maximum number of sockets that a Windows Sockets application can use is not affected by the manifest constant FD_SETSIZE. If an application is designed to be capable of working with more than 64 sockets using the select and WSAPoll functions, the implementor should define the manifest FD_SETSIZE in every source file before including the Winsock2.h header file.

            Windows上select支持的socket數量并不受宏FD_SETSIZE的影響,而僅僅受內存的影響。如果應用程序想使用超過FD_SETSIZE的socket,僅需要重新定義FD_SETSIZE即可。

            實際上稍微想想就可以明白,既然fd_set里面已經有一個socket的數量計數,那么select的實現完全可以使用這個計數,而不是FD_SETSIZE這個宏。那么結論是,select至少在Windows上并沒有socket支持數量的限制。當然效率問題這里不談。

            這看起來推翻了我們一直以來沒有深究的一個事實。

            Linux的實現

            在上面提到的MSDN中,其實已經提到了Windows與Berkeley Unix實現的不同。在select的API文檔中也看到了第一個參數并沒有說明其作用??聪翷inux的man

            nfds is the highest-numbered file descriptor in any of the three sets, plus 1.

            第一個參數簡單來說就是最大描述符+1。

            An fd_set is a fixed size buffer. Executing FD_CLR() or FD_SET() with a value of fd that is negative or is equal to or larger than FD_SETSIZE will result in undefined behavior.

            明確說了,如果調用FD_SET之類的宏fd超過了FD_SETSIZE將導致undefined behavior。也有人專門做了測試:select system call limitation in Linux。也有現實遇到的問題:socket file descriptor (1063) is larger than FD_SETSIZE (1024), you probably need to rebuild Apache with a larger FD_SETSIZE

            看起來在Linux上使用select確實有FD_SETSIZE的限制。有必要看下相關的實現 fd_set.h

            typedef __uint32_t      __fd_mask;
            
            /* 32 = 2 ^ 5 */
            #define __NFDBITS       (32)
            #define __NFDSHIFT      (5)
            #define __NFDMASK       (__NFDBITS - 1)
            
            /*
             * Select uses bit fields of file descriptors.  These macros manipulate
             * such bit fields.  Note: FD_SETSIZE may be defined by the user.
             */
            
            #ifndef FD_SETSIZE
            #define FD_SETSIZE      256
            #endif
            
            #define __NFD_SIZE      (((FD_SETSIZE) + (__NFDBITS - 1)) / __NFDBITS)
            
            typedef struct fd_set {
                __fd_mask       fds_bits[__NFD_SIZE];
            } fd_set;
            

            在這份實現中不同于Windows實現,它使用了位來表示fd??聪?code>FD_SET系列宏的大致實現:

            #define FD_SET(n, p)    \
               ((p)->fds_bits[(unsigned)(n) >> __NFDSHIFT] |= (1 << ((n) & __NFDMASK)))
            

            添加一個fd到fd_set中也不是Windows的遍歷,而是直接位運算。這里也有人對另一份類似實現做了剖析:linux的I/O多路轉接select的fd_set數據結構和相應FD_宏的實現分析。在APUE中也提到fd_set

            這種數據類型(fd_set)為每一可能的描述符保持了一位。

            既然fd_set中不包含其保存了多少個fd的計數,那么select的實現里要知道自己要處理多少個fd,那只能使用FD_SETSIZE宏去做判定,但Linux的實現選用了更好的方式,即通過第一個參數讓應用層告訴select需要處理的最大fd(這里不是數量)。那么其實現大概為:

            for (int i = 0; i < nfds; ++i) {
                if (FD_ISSET...
                   ...
            }
            

            如此看來,Linux的select實現則是受限于FD_SETSIZE的大小。這里也看到,fd_set使用位數組來保存fd,那么fd本身作為一個int數,其值就不能超過FD_SETSIZE。這不僅僅是數量的限制,還是其取值的限制。實際上,Linux上fd的取值是保證了小于FD_SETSIZE的(但不是不變的)Is the value of a Linux file descriptor always smaller than the open file limits?

            Each process is further limited via the setrlimit(2) RLIMIT_NOFILE per-process limit on the number of open files. 1024 is a common RLIMIT_NOFILE limit. (It’s very easy to change this limit via /etc/security/limits.conf.)

            fd的取值會小于RLIMIT_NOFILE,有很多方法可以改變這個值。這個值默認情況下和FD_SETSIZE應該是一樣的。這個信息告訴我們,Linux下fd的取值應該是從0開始遞增的(理論上,實際上還有stdin/stdout/stderr之類的fd)。這才能保證select的那些宏可以工作。

            應用層使用

            標準的select用法應該大致如下:

            while (true) {
                ...
                select(...)
                for-each socket {
                    if (FD_ISSET(fd, set))
                        ...
                }
            
                ...
            }
            

            即遍歷目前管理的fd,通過FD_ISSET去判定當前fd是否有IO事件。因為Windows的實現FD_ISSET都是一個循環,所以有了另一種不跨平臺的用法:

            while (true) {
                ...
                select(. &read_sockets, &write_sockets..)
                for-each read_socket {
                    use fd.fd_array[i)
                }
                ...
            }
            

            總結

            • Windows上select沒有fd數量的限制,但因為使用了循環來檢查,所以效率相對較低
            • Linux上selectFD_SETSIZE的限制,但其相對效率較高

            posted on 2014-06-01 23:45 Kevin Lynx 閱讀(4937) 評論(1)  編輯 收藏 引用 所屬分類: network

            評論

            # re: select真的有限制嗎 2014-06-06 13:23 liyou

            不錯,樓主做了自己的研究。  回復  更多評論   

            国产91色综合久久免费分享| 久久精品亚洲福利| 久久综合伊人77777麻豆| 久久w5ww成w人免费| 久久这里只有精品18| 亚洲女久久久噜噜噜熟女| 无码人妻久久一区二区三区蜜桃 | 久久av免费天堂小草播放| 99久久er这里只有精品18| 色88久久久久高潮综合影院| 亚洲精品国产美女久久久| 欧美黑人激情性久久| 久久精品国产第一区二区三区| 亚洲中文字幕无码久久2020| 亚洲AV日韩精品久久久久久| 成人妇女免费播放久久久| 精品永久久福利一区二区| 91久久香蕉国产熟女线看| 精品久久久久国产免费| 久久综合久久综合亚洲| 亚洲AV无一区二区三区久久 | 日本精品久久久久影院日本| 美女久久久久久| 亚洲AV日韩AV永久无码久久| 国产精品久久影院| 久久精品国产第一区二区| 久久久久久国产精品美女| 精品国产VA久久久久久久冰| 国产高清美女一级a毛片久久w| 色婷婷综合久久久久中文字幕| 老男人久久青草av高清| 久久香蕉一级毛片| 日日狠狠久久偷偷色综合96蜜桃| 久久久久久亚洲精品成人| 久久国产精品国语对白| 久久综合狠狠综合久久综合88| 91久久精品国产成人久久| 色88久久久久高潮综合影院| 色播久久人人爽人人爽人人片aV| 99久久国产热无码精品免费| 一级做a爰片久久毛片免费陪|