| 在linux的網(wǎng)絡(luò )編程中，很長(cháng)的時(shí)間都在使用select來(lái)做事件觸發(fā)。在linux新的內核中，有了一種替換它的機制，就是epoll。相比于select，epoll最大的好處在于它不會(huì )隨著(zhù)監聽(tīng)fd數目的增長(cháng)而降低效率。因為在內核中的select實(shí)現中，它是采用輪詢(xún)來(lái)處理的，輪詢(xún)的fd數目越多，自然耗時(shí)越多。并且，在linux/posix_types.h頭文件有這樣的聲明： #define __FD_SETSIZE 1024 表示select最多同時(shí)監聽(tīng)1024個(gè)fd，當然，可以通過(guò)修改頭文件再重編譯內核來(lái)擴大這個(gè)數目，但這似乎并不治本。 epoll的接口非常簡(jiǎn)單，一共就三個(gè)函數： 1.int epoll_create( int size ); //int close(int epfd); 創(chuàng )建一個(gè)epoll的句柄，size用來(lái)告訴內核這個(gè)監聽(tīng)的數目一共有多大。這個(gè)參數不同于select()中的第一個(gè)參數，給出最大監聽(tīng)的fd+1的 值。需要注意的是，當創(chuàng )建好epoll句柄后，它就是會(huì )占用一個(gè)fd值，在linux下如果查看/proc/進(jìn)程id/fd/，是能夠看到這個(gè)fd的，所 以在使用完epoll后，必須調用close()關(guān)閉，否則可能導致fd被耗盡。 2.int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event ); epoll的事件注冊函數，它不同與select()是在監聽(tīng)事件時(shí)告訴內核要監聽(tīng)什么類(lèi)型的事件，而是在這里先注冊要監聽(tīng)的事件類(lèi)型。第一個(gè)參數是epoll_create()的返回值，第二個(gè)參數表示動(dòng)作，用三個(gè)宏來(lái)表示： EPOLL_CTL_ADD：注冊新的fd到epfd中； EPOLL_CTL_MOD：修改已經(jīng)注冊的fd的監聽(tīng)事件； EPOLL_CTL_DEL：從epfd中刪除一個(gè)fd； 第三個(gè)參數是需要監聽(tīng)的fd，第四個(gè)參數是告訴內核需要監聽(tīng)什么事，struct epoll_event結構如下： struct epoll_event { __uint32_t events; /* Epoll events */ epoll_data_t data; /* User data variable */ } events可以是以下幾個(gè)宏的集合： EPOLLIN ：表示對應的文件描述符可以讀（包括對端SOCKET正常關(guān)閉）； EPOLLOUT：表示對應的文件描述符可以寫(xiě)； EPOLLPRI：表示對應的文件描述符有緊急的數據可讀（這里應該表示有帶外數據到來(lái)）； EPOLLERR：表示對應的文件描述符發(fā)生錯誤； EPOLLHUP：表示對應的文件描述符被掛斷； EPOLLET： 將EPOLL設為邊緣觸發(fā)(Edge Triggered)模式，這是相對于水平觸發(fā)(Level Triggered)來(lái)說(shuō)的。 EPOLLONESHOT：只監聽(tīng)一次事件，當監聽(tīng)完這次事件之后，如果還需要繼續監聽(tīng)這個(gè)socket的話(huà)，需要再次把這個(gè)socket加入到EPOLL隊列里 3. int epoll_wait(int epfd, struct epoll_event * events, int maxevents, int timeout); 等 待事件的產(chǎn)生，類(lèi)似于select()調用。參數events用來(lái)從內核得到事件的集合，maxevents告之內核這個(gè)events有多大，這個(gè) maxevents的值不能大于創(chuàng )建epoll_create()時(shí)的size，參數timeout是超時(shí)時(shí)間（毫秒，0會(huì )立即返回，-1將不確定，也有 說(shuō)法說(shuō)是永久阻塞）。該函數返回需要處理的事件數目，如返回0表示已超時(shí)。 從man手冊中，得到ET和LT的具體描述如下 EPOLL事件有兩種模型： Edge Triggered (ET) Level Triggered (LT) 假如有這樣一個(gè)例子： 1. 我們已經(jīng)把一個(gè)用來(lái)從管道中讀取數據的文件句柄(RFD)添加到epoll描述符 2. 這個(gè)時(shí)候從管道的另一端被寫(xiě)入了2KB的數據 3. 調用epoll_wait(2)，并且它會(huì )返回RFD，說(shuō)明它已經(jīng)準備好讀取操作 4. 然后我們讀取了1KB的數據 5. 調用epoll_wait(2)...... Edge Triggered 工作模式： 如 果我們在第1步將RFD添加到epoll描述符的時(shí)候使用了EPOLLET標志，那么在第5步調用epoll_wait(2)之后將有可能會(huì )掛起，因為剩 余的數據還存在于文件的輸入緩沖區內，而且數據發(fā)出端還在等待一個(gè)針對已經(jīng)發(fā)出數據的反饋信息。只有在監視的文件句柄上發(fā)生了某個(gè)事件的時(shí)候 ET 工作模式才會(huì )匯報事件。因此在第5步的時(shí)候，調用者可能會(huì )放棄等待仍在存在于文件輸入緩沖區內的剩余數據。在上面的例子中，會(huì )有一個(gè)事件產(chǎn)生在RFD句柄 上，因為在第2步執行了一個(gè)寫(xiě)操作，然后，事件將會(huì )在第3步被銷(xiāo)毀。因為第4步的讀取操作沒(méi)有讀空文件輸入緩沖區內的數據，因此我們在第5步調用 epoll_wait(2)完成后，是否掛起是不確定的。epoll工作在ET模式的時(shí)候，必須使用非阻塞套接口，以避免由于一個(gè)文件句柄的阻塞讀/阻塞 寫(xiě)操作把處理多個(gè)文件描述符的任務(wù)餓死。最好以下面的方式調用ET模式的epoll接口，在后面會(huì )介紹避免可能的缺陷。 i 基于非阻塞文件句柄 ii 只有當read(2)或者write(2)返回EAGAIN時(shí)才需要掛起，等待。但這并不是說(shuō)每次read()時(shí)都需要循環(huán)讀，直到讀到產(chǎn)生一個(gè)EAGAIN才認為此次事件處理完成，當read()返回的讀到的數據長(cháng)度小于請求的數據長(cháng)度時(shí)，就可以確定此時(shí)緩沖中已沒(méi)有數據了，也就可以認為此事讀事件已處理完成。 Level Triggered 工作模式 相 反的，以L(fǎng)T方式調用epoll接口的時(shí)候，它就相當于一個(gè)速度比較快的poll(2)，并且無(wú)論后面的數據是否被使用，因此他們具有同樣的職能。因為即 使使用ET模式的epoll，在收到多個(gè)chunk的數據的時(shí)候仍然會(huì )產(chǎn)生多個(gè)事件。調用者可以設定EPOLLONESHOT標志，在 epoll_wait(2)收到事件后epoll會(huì )與事件關(guān)聯(lián)的文件句柄從epoll描述符中禁止掉。因此當EPOLLONESHOT設定后，使用帶有 EPOLL_CTL_MOD標志的epoll_ctl(2)處理文件句柄就成為調用者必須作的事情。 然后詳細解釋ET, LT: LT(level triggered)是缺省的工作方式，并且同時(shí)支持block和no-block socket.在這種做法中，內核告訴你一個(gè)文件描述符是否就緒了，然后你可以對這個(gè)就緒的fd進(jìn)行IO操作。如果你不作任何操作，內核還是會(huì )繼續通知你 的，所以，這種模式編程出錯誤可能性要小一點(diǎn)。傳統的select/poll都是這種模型的代表． ET(edge-triggered) 是高速工作方式，只支持no-block socket。在這種模式下，當描述符從未就緒變?yōu)榫途w時(shí)，內核通過(guò)epoll告訴你。然后它會(huì )假設你知道文件描述符已經(jīng)就緒，并且不會(huì )再為那個(gè)文件描述 符發(fā)送更多的就緒通知，直到你做了某些操作導致那個(gè)文件描述符不再為就緒狀態(tài)了(比如，你在發(fā)送，接收或者接收請求，或者發(fā)送接收的數據少于一定量時(shí)導致 了一個(gè)EWOULDBLOCK 錯誤）。但是請注意，如果一直不對這個(gè)fd作IO操作(從而導致它再次變成未就緒)，內核不會(huì )發(fā)送更多的通知(only once),不過(guò)在TCP協(xié)議中，ET模式的加速效用仍需要更多的benchmark確認（這句話(huà)不理解）。 在 許多測試中我們會(huì )看到如果沒(méi)有大量的idle -connection或者dead-connection，epoll的效率并不會(huì )比select/poll高很多，但是當我們遇到大量的idle- connection(例如WAN環(huán)境中存在大量的慢速連接)，就會(huì )發(fā)現epoll的效率大大高于select/poll。（未測試） 另外，當使用epoll的ET模型來(lái)工作時(shí)，當產(chǎn)生了一個(gè)EPOLLIN事件后， 讀數據的時(shí)候需要考慮的是當recv()返回的大小如果等于請求的大小，那么很有可能是緩沖區還有數據未讀完，也意味著(zhù)該次事件還沒(méi)有處理完，所以還需要再次讀取： while(rs) { buflen = recv(activeevents[i].data.fd, buf, sizeof(buf), 0); if(buflen < 0) { // 由于是非阻塞的模式,所以當errno為EAGAIN時(shí),表示當前緩沖區已無(wú)數據可讀 // 在這里就當作是該次事件已處理處. if(errno == EAGAIN) break; else return; } else if(buflen == 0) { // 這里表示對端的socket已正常關(guān)閉. } if(buflen == sizeof(buf) rs = 1; // 需要再次讀取 else rs = 0; } 還 有，假如發(fā)送端流量大于接收端的流量(意思是epoll所在的程序讀比轉發(fā)的socket要快),由于是非阻塞的socket,那么send()函數雖然 返回,但實(shí)際緩沖區的數據并未真正發(fā)給接收端,這樣不斷的讀和發(fā)，當緩沖區滿(mǎn)后會(huì )產(chǎn)生EAGAIN錯誤(參考man send),同時(shí),不理會(huì )這次請求發(fā)送的數據.所以,需要封裝socket_send()的函數用來(lái)處理這種情況,該函數會(huì )盡量將數據寫(xiě)完再返回，返回- 1表示出錯。在socket_send()內部,當寫(xiě)緩沖已滿(mǎn)(send()返回-1,且errno為EAGAIN),那么會(huì )等待后再重試.這種方式并不 很完美,在理論上可能會(huì )長(cháng)時(shí)間的阻塞在socket_send()內部,但暫沒(mé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) { // 當send收到信號時(shí),可以繼續寫(xiě),但這里返回-1. if(errno == EINTR) return -1; // 當socket是非阻塞時(shí),如返回此錯誤,表示寫(xiě)緩沖隊列已滿(mǎn), // 在這里做延時(shí)后再重試. if(errno == EAGAIN) { usleep(1000); continue; } return -1; } if((size_t)tmp == total) return buflen; total -= tmp; p += tmp; } return tmp; } |
聯(lián)系客服
