C++ 技術(shù)中心

　　epoll則沒(méi)有這樣的限制，epoll支持的最大鏈接數(shù)是最大可打開(kāi)的文件的數(shù)目。epoll只對(duì)活躍的socket進(jìn)行操作——這是因?yàn)閑poll是根據(jù)每個(gè)fd上面的callback函數(shù)實(shí)現(xiàn)的。那么，只有活躍的socket才會(huì)主動(dòng)地調(diào)用callback函數(shù)。在一個(gè)高速的LAN環(huán)境，如果幾乎所有的socket都是活躍的，epoll的效率比select會(huì)稍微有下降。

　　使用mmap加速內(nèi)核與用戶空間的消息傳遞。無(wú)論select，poll都需要內(nèi)核把FD消息通知給用戶空間，如何避免不必要的內(nèi)存拷貝，在這點(diǎn)上epoll通過(guò)內(nèi)核與用戶空間mmap同一塊內(nèi)存空間實(shí)現(xiàn)的。

　　epoll有兩種工作方式LT（level triggered）和ET（edge triggered）。

　　LT（level triggered）是缺省的工作方式，支持block和non-block socket。在這種模式下，內(nèi)核告訴你一個(gè)文件描述符已經(jīng)就緒了，然后對(duì)這個(gè)描述符進(jìn)行io操作。如果你不作任何操作，內(nèi)核還會(huì)繼續(xù)通知你的。所以，這種模式編程出錯(cuò)可能性要小一點(diǎn)。傳統(tǒng)的select/poll都是這種模型的代表。

　　ET（edge triggered）高速工作方式，只支持no-block描述符。在這種模式下，當(dāng)描述符由未就緒變?yōu)榫途w時(shí)，內(nèi)核通過(guò)epoll告訴你。然后它假設(shè)你知道文件描述符已經(jīng)就緒，并且不再為那個(gè)描述符發(fā)送更多的就緒通知，直到你做了某些操作導(dǎo)致描述符不再是就緒狀態(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)。

epoll接口

int epoll_create(int size)

創(chuàng)建一個(gè)epoll句柄，size告訴內(nèi)核這個(gè)監(jiān)聽(tīng)的數(shù)目一共有多大。這個(gè)參數(shù)不同于select的第一個(gè)參數(shù)，給出最大的fd+1值。需要注意的是，當(dāng)創(chuàng)建好epoll句柄后，它就會(huì)占用一個(gè)fd值，在linux下如果查看/proc/prodid/fd/能夠看到這個(gè)fd的，所以使用完epoll后，必須調(diào)用close關(guān)閉。

int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event)

epoll事件注冊(cè)函數(shù)，它不同于select是在監(jiān)聽(tīng)事件時(shí)告訴內(nèi)核要監(jiān)聽(tīng)什么類型的事件，而是在這里先注冊(cè)要監(jiān)聽(tīng)的事件類型。

epfd：epoll描述符

op：EPOLL_CTL_ADD 注冊(cè)新的fd

EPOLL_CTL_MOD 修改已注冊(cè)的fd的監(jiān)聽(tīng)事件

EPOLL_CTL_DEL 從epfd中刪除一個(gè)fd

struct epoll_event {

__uint32_t event; /* EPOLLIN 可以讀（包括對(duì)端socket正常關(guān)閉）

EPOLLOUT 可以寫(xiě)

EPOLLPRI 有緊急數(shù)據(jù)可讀（這里應(yīng)該表示有帶外數(shù)據(jù)到來(lái)）

EPOLLERR 對(duì)應(yīng)文件描述符發(fā)生錯(cuò)誤

EPOLLHUP 對(duì)應(yīng)的文件描述符被掛斷

EPOLLET ET工作模式

EPOLLONESHOT 只監(jiān)聽(tīng)一次事件，當(dāng)監(jiān)聽(tīng)完這次事件后，還需要繼續(xù)監(jiān)聽(tīng)的話，需要再次把fd加入到監(jiān)聽(tīng)隊(duì)列里。

epoll_data_t data; /* user data */

};

typedef union epoll_data {
void ptr;
int fd;
__uint32_t u32;
__uint64_t u64;
} epoll_data_t;

int epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout)

等待事件的產(chǎn)生，類似于select。

events，從內(nèi)核得到事件的總和

maxevents，告訴內(nèi)核這個(gè)events有多大，不能大于epoll_create size 值

timeout，超時(shí)時(shí)間（毫秒）。0：立即返回，-1 不確定或永久阻塞

返回，0：超時(shí)；否則 事件個(gè)數(shù)

假如有這樣一個(gè)例子：
1. 我們已經(jīng)把一個(gè)用來(lái)從管道中讀取數(shù)據(jù)的文件句柄(RFD)添加到epoll描述符
2. 這個(gè)時(shí)候從管道的另一端被寫(xiě)入了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)槭Ｓ嗟臄?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è)寫(xiě)操作，然后，事件將會(huì)在第3步被銷毀。因?yàn)榈?步的讀取操作沒(méi)有讀空文件輸入緩沖區(qū)內(nèi)的數(shù)據(jù)，因此我們?cè)诘?步調(diào)用 epoll_wait(2)完成后，是否掛起是不確定的。epoll工作在ET模式的時(shí)候，必須使用非阻塞套接口，以避免由于一個(gè)文件句柄的阻塞讀/阻塞寫(xiě)操作把處理多個(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í)緩沖中已沒(méi)有數(shù)據(jù)了，也就可以認(rèn)為此事讀事件已處理完成。

另外，當(dāng)使用epoll的ET模型來(lái)工作時(shí)，當(dāng)產(chǎn)生了一個(gè)EPOLLIN事件后，
讀數(shù)據(jù)的時(shí)候需要考慮的是當(dāng)recv()返回的大小如果等于請(qǐng)求的大小，那么很有可能是緩沖區(qū)還有數(shù)據(jù)未讀完，也意味著該次事件還沒(méi)有處理完，所以還需要再次讀取：
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ù)寫(xiě)完再返回，返回-1表示出錯(cuò)。在socket_send()內(nèi)部,當(dāng)寫(xiě)緩沖已滿(send()返回-1,且errno為EAGAIN),那么會(huì)等待后再重試.這種方式并不很完美,在理論上可能會(huì)長(zhǎng)時(shí)間的阻塞在socket_send()內(nèi)部,但暫沒(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)
{
// 當(dāng)send收到信號(hào)時(shí),可以繼續(xù)寫(xiě),但這里返回-1.
if(errno == EINTR)
return -1;

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

return -1;
}

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

total -= tmp;
p += tmp;
}

return tmp;
}