• <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>
            posts - 297,  comments - 15,  trackbacks - 0
            在linux的網(wǎng)絡(luò)編程中,很長(zhǎng)的時(shí)間都在使用select來(lái)做事件觸發(fā)。在linux新的內(nèi)核中,有了一種替換它的機(jī)制,就是epoll。
            相比 于select,epoll最大的好處在于它不會(huì)隨著監(jiān)聽fd數(shù)目的增長(zhǎng)而降低效率。因?yàn)樵趦?nèi)核中的select實(shí)現(xiàn)中,它是采用輪詢來(lái)處理的,輪詢的 fd數(shù)目越多,自然耗時(shí)越多。并且,在linux/posix_types.h頭文件有這樣的聲明:
            #define __FD_SETSIZE    1024
            表示select最多同時(shí)監(jiān)聽 1024個(gè)fd,當(dāng)然,可以通過(guò)修改頭文件再重編譯內(nèi)核來(lái)擴(kuò)大這個(gè)數(shù)目,但這似乎并不治本。

            epoll的接口非常簡(jiǎn)單,一共就三個(gè)函數(shù):
            1. int epoll_create(int size);
            創(chuàng) 建一個(gè)epoll的句柄,size用來(lái)告訴內(nèi)核這個(gè)監(jiān)聽的數(shù)目一共有多大。這個(gè)參數(shù)不同于select()中的第一個(gè)參數(shù),給出最大監(jiān)聽的fd+1的值。 需要注意的是,當(dāng)創(chuàng)建好epoll句柄后,它就是會(huì)占用一個(gè)fd值,在linux下如果查看/proc/進(jìn)程id/fd/,是能夠看到這個(gè)fd的,所以在 使用完epoll后,必須調(diào)用close()關(guān)閉,否則可能導(dǎo)致fd被耗盡。


            2. int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);
            epoll的事件注冊(cè)函數(shù),它不同與select()是在監(jiān)聽事件時(shí)告訴內(nèi)核要監(jiān)聽什么 類型的事件,而是在這里先注冊(cè)要監(jiān)聽的事件類型。第一個(gè)參數(shù)是epoll_create()的返回值,第二個(gè)參數(shù)表示動(dòng)作,用三個(gè)宏來(lái)表示:
            EPOLL_CTL_ADD: 注冊(cè)新的fd到epfd中;
            EPOLL_CTL_MOD:修改已經(jīng)注冊(cè)的fd的監(jiān)聽事件;
            EPOLL_CTL_DEL:從epfd中刪除 一個(gè)fd;
            第三個(gè)參數(shù)是需要監(jiān)聽的fd,第四個(gè)參數(shù)是告訴內(nèi)核需要監(jiān)聽什么事,struct epoll_event結(jié)構(gòu)如下:
            struct epoll_event {
              __uint32_t events;  /* Epoll events */
              epoll_data_t data;  /* User data variable */
            };

            events可以是以下幾個(gè)宏 的集合:
            EPOLLIN :表示對(duì)應(yīng)的文件描述符可以讀(包括對(duì)端SOCKET正常關(guān)閉);
            EPOLLOUT:表示對(duì)應(yīng)的文件描述符可以 寫;
            EPOLLPRI:表示對(duì)應(yīng)的文件描述符有緊急的數(shù)據(jù)可讀(這里應(yīng)該表示有帶外數(shù)據(jù)到來(lái));
            EPOLLERR:表示對(duì)應(yīng)的文件描述符 發(fā)生錯(cuò)誤;
            EPOLLHUP:表示對(duì)應(yīng)的文件描述符被掛斷;
            EPOLLET: 將EPOLL設(shè)為邊緣觸發(fā)(Edge Triggered)模式,這是相對(duì)于水平觸發(fā)(Level Triggered)來(lái)說(shuō)的。
            EPOLLONESHOT:只監(jiān)聽一次事件,當(dāng)監(jiān)聽完 這次事件之后,如果還需要繼續(xù)監(jiān)聽這個(gè)socket的話,需要再次把這個(gè)socket加入到EPOLL隊(duì)列里


            3. int epoll_wait(int epfd, struct epoll_event * events, int maxevents, int timeout);
            等待事件的產(chǎn)生,類似于 select()調(diào)用。參數(shù)events用來(lái)從內(nèi)核得到事件的集合,maxevents告之內(nèi)核這個(gè)events有多大,這個(gè)maxevents的值不能 大于創(chuàng)建epoll_create()時(shí)的size,參數(shù)timeout是超時(shí)時(shí)間(毫秒,0會(huì)立即返回,-1將不確定,也有說(shuō)法說(shuō)是永久阻塞)。該函數(shù) 返回需要處理的事件數(shù)目,如返回0表示已超時(shí)。

            --------------------------------------------------------------------------------------------

            從 man手冊(cè)中,得到ET和LT的具體描述如下

            EPOLL事件有兩種模型:
            Edge Triggered (ET)
            Level Triggered (LT)

            假如有這樣一個(gè)例子:
            1. 我們已經(jīng)把一個(gè)用來(lái)從管道中讀取數(shù)據(jù)的文件句柄(RFD)添加到epoll描述符
            2. 這個(gè)時(shí)候從管道的另一端被寫入了2KB的數(shù)據(jù)
            3. 調(diào)用epoll_wait(2),并且它會(huì)返回RFD,說(shuō)明它已經(jīng)準(zhǔn)備好讀取操作
            4. 然后我們讀取了1KB的數(shù)據(jù)
            5. 調(diào)用epoll_wait(2)......

            Edge Triggered 工作模式:
            如果我們?cè)诘?步將RFD添加到 epoll描述符的時(shí)候使用了EPOLLET標(biāo)志,那么在第5步調(diào)用epoll_wait(2)之后將有可能會(huì)掛起,因?yàn)槭S嗟臄?shù)據(jù)還存在于文件的輸入緩 沖區(qū)內(nèi),而且數(shù)據(jù)發(fā)出端還在等待一個(gè)針對(duì)已經(jīng)發(fā)出數(shù)據(jù)的反饋信息。只有在監(jiān)視的文件句柄上發(fā)生了某個(gè)事件的時(shí)候 ET 工作模式才會(huì)匯報(bào)事件。因此在第5步的時(shí)候,調(diào)用者可能會(huì)放棄等待仍在存在于文件輸入緩沖區(qū)內(nèi)的剩余數(shù)據(jù)。在上面的例子中,會(huì)有一個(gè)事件產(chǎn)生在RFD句柄 上,因?yàn)樵诘?步執(zhí)行了一個(gè)寫操作,然后,事件將會(huì)在第3步被銷毀。因?yàn)榈?步的讀取操作沒有讀空文件輸入緩沖區(qū)內(nèi)的數(shù)據(jù),因此我們?cè)诘?步調(diào)用 epoll_wait(2)完成后,是否掛起是不確定的。epoll工作在ET模式的時(shí)候,必須使用非阻塞套接口,以避免由于一個(gè)文件句柄的阻塞讀/阻塞 寫操作把處理多個(gè)文件描述符的任務(wù)餓死。最好以下面的方式調(diào)用ET模式的epoll接口,在后面會(huì)介紹避免可能的缺陷。
               i    基于非阻塞文件句柄
               ii   只有當(dāng)read(2)或者write(2)返回EAGAIN時(shí)才需要掛起,等待。但這并不是說(shuō)每次read()時(shí)都需要循環(huán)讀, 直到讀到產(chǎn)生一個(gè)EAGAIN才認(rèn)為此次事件處理完成,當(dāng)read()返回的讀到的數(shù)據(jù)長(zhǎng)度小于請(qǐng)求的數(shù)據(jù)長(zhǎng)度時(shí),就可以確定此時(shí)緩沖中已沒有數(shù)據(jù)了,也 就可以認(rèn)為此事讀事件已處理完成。

            Level Triggered 工作模式
            相反的,以LT方式調(diào)用epoll接 口的時(shí)候,它就相當(dāng)于一個(gè)速度比較快的poll(2),并且無(wú)論后面的數(shù)據(jù)是否被使用,因此他們具有同樣的職能。因?yàn)榧词故褂肊T模式的epoll,在收 到多個(gè)chunk的數(shù)據(jù)的時(shí)候仍然會(huì)產(chǎn)生多個(gè)事件。調(diào)用者可以設(shè)定EPOLLONESHOT標(biāo)志,在 epoll_wait(2)收到事件后epoll會(huì)與事件關(guān)聯(lián)的文件句柄從epoll描述符中禁止掉。因此當(dāng)EPOLLONESHOT設(shè)定后,使用帶有 EPOLL_CTL_MOD標(biāo)志的epoll_ctl(2)處理文件句柄就成為調(diào)用者必須作的事情。


            然后詳細(xì)解釋ET, LT:

            LT(level triggered)是缺省的工作方式,并且同時(shí)支持block和no-block socket.在這種做法中,內(nèi)核告訴你一個(gè)文件描述符是否就緒了,然后你可以對(duì)這個(gè)就緒的fd進(jìn)行IO操作。如果你不作任何操作,內(nèi)核還是會(huì)繼續(xù)通知你 的,所以,這種模式編程出錯(cuò)誤可能性要小一點(diǎn)。傳統(tǒng)的select/poll都是這種模型的代表.

            ET(edge-triggered) 是高速工作方式,只支持no-block socket。在這種模式下,當(dāng)描述符從未就緒變?yōu)榫途w時(shí),內(nèi)核通過(guò)epoll告訴你。然后它會(huì)假設(shè)你知道文件描述符已經(jīng)就緒,并且不會(huì)再為那個(gè)文件描述 符發(fā)送更多的就緒通知,直到你做了某些操作導(dǎo)致那個(gè)文件描述符不再為就緒狀態(tài)了(比如,你在發(fā)送,接收或者接收請(qǐng)求,或者發(fā)送接收的數(shù)據(jù)少于一定量時(shí)導(dǎo)致 了一個(gè)EWOULDBLOCK 錯(cuò)誤)。但是請(qǐng)注意,如果一直不對(duì)這個(gè)fd作IO操作(從而導(dǎo)致它再次變成未就緒),內(nèi)核不會(huì)發(fā)送更多的通知(only once),不過(guò)在TCP協(xié)議中,ET模 式的加速效用仍需要更多的benchmark確認(rèn)(這句話不理解)。

            在許多測(cè)試中我們會(huì)看到如果沒有大量的idle -connection或者dead-connection,epoll的效率并不會(huì)比select/poll高很多,但是當(dāng)我們遇到大量的idle- connection(例如WAN環(huán)境中存在大量的慢速連接),就會(huì)發(fā)現(xiàn)epoll的效率大大高于select/poll。(未測(cè)試)



            另 外,當(dāng)使用epoll的ET模型來(lái)工作時(shí),當(dāng)產(chǎn)生了一個(gè)EPOLLIN事件后,
            讀數(shù)據(jù)的時(shí)候需要考慮的是當(dāng)recv()返回的大小如果等于請(qǐng)求的大小,那么很有可能是緩沖區(qū)還有數(shù)據(jù)未讀完,也意味著該次事件還沒有處理 完,所以還需要再次讀取
            while(rs)
            {
              buflen = recv(activeevents[i].data.fd, buf, sizeof(buf), 0);
              if(buflen < 0)
              {
                // 由于是非阻塞的模式,所以當(dāng)errno為EAGAIN時(shí),表示當(dāng)前緩沖區(qū)已無(wú)數(shù)據(jù)可讀
                // 在這里就當(dāng)作是該次事件已處理處.
                if(errno == EAGAIN)
                 break;
                else
                 return;
               }
               else if(buflen == 0)
               {
                 // 這里表示對(duì)端的socket已正常關(guān)閉.
               }
               if(buflen == sizeof(buf)
                 rs = 1;   // 需要再次讀取
               else
                 rs = 0;
            }


            還有,假如發(fā)送端流量大于接收端的流量(意思是epoll所在的程序讀比轉(zhuǎn)發(fā)的socket要快),由 于是非阻塞的socket,那么send()函數(shù)雖然返回,但實(shí)際緩沖區(qū)的數(shù)據(jù)并未真正發(fā)給接收端,這樣不斷的讀和發(fā),當(dāng)緩沖區(qū)滿后會(huì)產(chǎn)生EAGAIN錯(cuò) 誤(參考man send),同時(shí),不理會(huì)這次請(qǐng)求發(fā)送的數(shù)據(jù).所以,需要封裝socket_send()的函數(shù)用來(lái)處理這種情況,該函數(shù)會(huì)盡量將數(shù)據(jù)寫完再返回,返回 -1表示出錯(cuò)。在socket_send()內(nèi)部,當(dāng)寫緩沖已滿(send()返回-1,且errno為EAGAIN),那么會(huì)等待后再重試.這種方式并 不很完美,在理論上可能會(huì)長(zhǎng)時(shí)間的阻塞在socket_send()內(nèi)部,但暫沒有更好的辦法.

            ssize_t socket_send(int sockfd, const char* buffer, size_t buflen)
            {
              ssize_t tmp;
              size_t total = buflen;
              const char *p = buffer;

              while(1)
              {
                tmp = send(sockfd, p, total, 0);
                if(tmp < 0)
                {
                  // 當(dāng)send收到信號(hào)時(shí),可以繼續(xù)寫,但這里返回-1.
                  if(errno == EINTR)
                    return -1;

                  // 當(dāng)socket是非阻塞時(shí),如返回此錯(cuò)誤,表示寫緩沖隊(duì)列已滿,
                  // 在這里做延時(shí)后再重試.
                  if(errno == EAGAIN)
                  {
                    usleep(1000);
                    continue;
                  }

                  return -1;
                }

                if((size_t)tmp == total)
                  return buflen;

                total -= tmp;
                p += tmp;
              }

              return tmp;
            }

            from:
            http://www.cnblogs.com/OnlyXP/archive/2007/08/10/851222.html
            posted on 2010-05-06 15:12 chatler 閱讀(583) 評(píng)論(0)  編輯 收藏 引用 所屬分類: Socket
            <2010年6月>
            303112345
            6789101112
            13141516171819
            20212223242526
            27282930123
            45678910

            常用鏈接

            留言簿(10)

            隨筆分類(307)

            隨筆檔案(297)

            algorithm

            Books_Free_Online

            C++

            database

            Linux

            Linux shell

            linux socket

            misce

            • cloudward
            • 感覺這個(gè)博客還是不錯(cuò),雖然做的東西和我不大相關(guān),覺得看看還是有好處的

            network

            OSS

            • Google Android
            • Android is a software stack for mobile devices that includes an operating system, middleware and key applications. This early look at the Android SDK provides the tools and APIs necessary to begin developing applications on the Android platform using the Java programming language.
            • os161 file list

            overall

            搜索

            •  

            最新評(píng)論

            閱讀排行榜

            評(píng)論排行榜

            亚洲精品tv久久久久久久久久| 国产精品中文久久久久久久| 久久久久久久精品妇女99| 女人香蕉久久**毛片精品| 国产成人精品综合久久久久| 久久久久久久亚洲精品| 国产免费久久久久久无码| 青青青国产精品国产精品久久久久 | 成人资源影音先锋久久资源网| 狠狠精品久久久无码中文字幕| 久久99这里只有精品国产| 伊人久久国产免费观看视频| 青青草国产97免久久费观看| 少妇久久久久久被弄到高潮| 日韩va亚洲va欧美va久久| 无码任你躁久久久久久| 亚洲国产婷婷香蕉久久久久久| 亚洲欧美精品一区久久中文字幕| 久久se精品一区精品二区国产| 久久久久综合国产欧美一区二区| 久久亚洲电影| 青青草原综合久久大伊人| 奇米综合四色77777久久| 久久精品国产亚洲AV电影| 久久久精品午夜免费不卡| 国产69精品久久久久99尤物| 久久se这里只有精品| 久久久久久久久66精品片| 亚洲国产美女精品久久久久∴| 久久99精品久久久久久hb无码| 国产99久久精品一区二区| 久久精品成人免费国产片小草| 久久久黄色大片| 国产精品久久久久影视不卡| 久久91这里精品国产2020| 无码八A片人妻少妇久久| 久久精品亚洲日本波多野结衣| 久久se这里只有精品| 色婷婷综合久久久久中文 | 国产激情久久久久影院小草| 久久综合伊人77777麻豆|