• <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>

            Bugs

            MMORPG game develop.

            Epoll筆記!

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


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

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


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

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

            ET(edge-triggered)是高速工作方式,只支持no-block socket。在這種模式下,當描述符從未就緒變為就緒時,內核通過epoll告訴你。然后它會假設你知道文件描述符已經就緒,并且不會再為那個文件描述符發送更多的就緒通知,直到你做了某些操作導致那個文件描述符不再為就緒狀態了(比如,你在發送,接收或者接收請求,或者發送接收的數據少于一定量時導致了一個EWOULDBLOCK 錯誤)。但是請注意,如果一直不對這個fd作IO操作(從而導致它再次變成未就緒),內核不會發送更多的通知(only once),不過在TCP協議中,ET模式的加速效用仍需要更多的benchmark確認

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


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

            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)
                {
                  // 當send收到信號時,可以繼續寫,但這里返回-1.
                  if(errno == EINTR)
                    return -1;

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

                  return -1;
                }

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

                total -= tmp;
                p += tmp;
              }

              return tmp;
            }

            posted on 2008-06-23 10:17 Bugs 閱讀(1539) 評論(6)  編輯 收藏 引用

            評論

            # re: Epoll筆記! 2008-06-23 10:25 Bugs

            /*
            這種方式并不很完美,在理論上可能會長時間的阻塞在socket_send()內部,但暫沒有更好的辦法.*/
            這種情況下,比較好的方法是為該socket關聯一個寫數據隊列或緩沖,本次寫失敗之后,等待epoll的下一次寫事件通知,再訪問該關聯數據隊列,再次發送。  回復  更多評論   

            # re: Epoll筆記![未登錄] 2008-06-23 12:25 CppExplore

            socket本身有發送緩沖區的,不必再關聯寫數據隊列或緩存。不放心可以開大緩沖區。  回復  更多評論   

            # re: Epoll筆記! 2008-06-24 08:39 飯中淹

            額外的一個寫數據隊列或者緩沖是很重要的。
            特別是需要處理很多socket的時候。

            而且
            EPOLL可以和線程池結合起來使用。用一個隊列和一個線程池來模擬
            IOCP,效率可能會比較高。
              回復  更多評論   

            # re: Epoll筆記! 2008-06-24 11:08 Bugs

            @飯中淹
            更加期待*nix下的AIO對套接字的支持。
            完全就是與IOCP模式相同。
              回復  更多評論   

            # re: Epoll筆記![未登錄] 2008-06-24 11:32 cppexplore

            沒覺得有什么必要性,每個socket都有自己的緩存的,不是共用的,再引入的復雜性和產出之間權衡下。網絡層上接線程消息隊列,屬于系統線程劃分的范疇,不僅epoll可以 select、poll等每個都可以。
            完全與iocp相同,自己封裝就可,僅僅是外在的表現形式,并不是穿了一件AIO的外衣 就有AIO的性能。  回復  更多評論   

            # re: Epoll筆記! 2008-06-25 21:54 Hellfire

            用epoll模擬iocp, asio就是這么干的。
            效率上肯定不如原生的AIO來的好,
            如果是跨平臺的高效框架,也可以作為一種考慮。  回復  更多評論   

            av无码久久久久不卡免费网站 | 久久亚洲AV成人无码软件| 久久久WWW免费人成精品| 99久久www免费人成精品| 久久伊人五月丁香狠狠色| 国产成人精品久久综合| 久久棈精品久久久久久噜噜| 国产亚洲精午夜久久久久久| 欧美日韩精品久久久久| 97超级碰碰碰久久久久| 亚洲中文久久精品无码ww16| 久久99热这里只有精品国产| 欧美午夜精品久久久久免费视| 久久99精品国产麻豆不卡| 亚洲αv久久久噜噜噜噜噜| 无码国内精品久久综合88| 久久精品无码一区二区三区日韩| 国产精品久久99| 久久精品天天中文字幕人妻| 久久久婷婷五月亚洲97号色| 国产69精品久久久久APP下载| 热久久国产欧美一区二区精品| 久久精品国产99久久丝袜| 久久久久亚洲AV综合波多野结衣| 国内精品久久人妻互换| 99久久精品国产高清一区二区| 99久久国产综合精品麻豆| 国内精品久久久久久99蜜桃 | 1000部精品久久久久久久久| 亚洲综合久久夜AV | 人妻精品久久无码专区精东影业| 国产精品视频久久| 香蕉99久久国产综合精品宅男自 | 久久香蕉国产线看观看99| 久久久久女人精品毛片| 久久久久久国产精品无码超碰| 婷婷综合久久中文字幕| 伊人久久精品影院| 久久久九九有精品国产| 日韩影院久久| 99久久精品国产一区二区|