本人用epoll來實現(xiàn)多路復(fù)用，epoll觸發(fā)模式有兩種：

• ET（邊緣模式）
• LT（水平模式）

LT模式

是標(biāo)準(zhǔn)模式，意味著每次epoll_wait()返回后，事件處理后，如果之后還有數(shù)據(jù)，會不斷觸發(fā)，也就是說，一個套接字上一次完整的數(shù)據(jù)，epoll_wait()可能會返回多次，直到?jīng)]有數(shù)據(jù)為止。

ET模式

也稱高效模式，有數(shù)據(jù)過來后，epoll_wait()會返回一次，一段時間內(nèi)，該套接字就算有數(shù)據(jù)源源不斷地過來，epoll_wait()也不會返回了。這里注意，是一段時間，不代表這個套接字上有數(shù)據(jù)就只觸發(fā)一次。時間過長，還是會返回多次的。比如我寫FTP用了epoll+多線程，但是每次套接字上有信息就開線程處理，同一時間內(nèi)希望一個套接字只被一個線程持有，但是因為文件傳輸時間過長，就算使用ET模式，套接字還是會返回多次。這里要特別強調(diào)一個參數(shù)EPOLLONESHOT，如果要保證套接字同一時段只被一個線程處理，必須加上。解決方案：給accept()后的套接字加上參數(shù)EPOLLONESHOT，線程結(jié)束后處理完之后，再重置EPOLLONESHOT屬性，但是，千萬不可以給listen()后的監(jiān)聽套接字設(shè)置此屬性，這會造成同一時刻只能處理一個連接的情況。

深入理解EPOLLONESHOT事件

即使使用ET模式，一個socket上的某個事件還是可能被觸發(fā)多次，這是跟數(shù)據(jù)報的大小有關(guān)系，常見的情景就是一個線程，而在數(shù)據(jù)的處理過程中該socket上又有新數(shù)據(jù)可讀（EPOLLIN再次被觸發(fā)），此時另外一個線程被喚醒處理這些新的數(shù)據(jù)，于是出現(xiàn)了兩個線程同時操作一個socket，為了避免這種情況，就可以采用epoll的EPOLLONESPOT事件。同時要注意，注冊了EPOLLONESHOT事件的socket一旦被某個線程處理完畢，該線程就應(yīng)該立即重置這個socket的EPOLLONESHOT的事件，以確保這個socket下次可讀時，其EPOLLIN事件被觸發(fā)，進(jìn)而讓其他的工作線程有機會繼續(xù)處理這個socket。

網(wǎng)絡(luò)事件EAGIN

在一個非阻塞的socket上調(diào)用read/write函數(shù), 返回EAGAIN或者EWOULDBLOCK(注: EAGAIN就是EWOULDBLOCK)從字面上看, 意思是:EAGAIN: 再試一次，EWOULDBLOCK: 如果這是一個阻塞socket, 操作將被block，perror輸出: Resource temporarily unavailable.

小結(jié):

這個錯誤表示資源暫時不夠，能read時，讀緩沖區(qū)沒有數(shù)據(jù)，或者write時，寫緩沖區(qū)滿了。遇到這種情況，如果是阻塞socket，read/write就要阻塞掉。而如果是非阻塞socket，read/write立即返回-1， 同時errno設(shè)置為EAGAIN。所以，對于阻塞socket，read/write返回-1代表網(wǎng)絡(luò)出錯了。但對于非阻塞socket，read/write返回-1不一定網(wǎng)絡(luò)真的出錯了?？赡苁荝esource temporarily unavailable。這時你應(yīng)該再試，直到Resource available。

EAGAIN: 再試一次，EWOULDBLOCK: 如果這是一個阻塞socket, 操作將被block，perror輸出: Resource temporarily unavailable。這個錯誤表示資源暫時不夠，能read時，讀緩沖區(qū)沒有數(shù)據(jù)，或者write時，寫緩沖區(qū)滿了。遇到這種情況，如果是阻塞socket，read/write就要阻塞掉。而如果是非阻塞socket，read/write立即返回-1， 同時errno設(shè)置為EAGAIN。所以，對于阻塞socket，read/write返回-1代表網(wǎng)絡(luò)出錯了。但對于非阻塞socket，read/write返回-1不一定網(wǎng)絡(luò)真的出錯了。可能是Resource temporarily unavailable。這時你應(yīng)該再試，直到Resource available。

綜上，對于non-blocking的socket，正確的讀寫操作為: 讀：忽略掉errno = EAGAIN的錯誤，下次繼續(xù)讀 寫：忽略掉errno = EAGAIN的錯誤，下次繼續(xù)寫

對于select和epoll的LT模式，這種讀寫方式是沒有問題的。但對于epoll的ET模式，這種方式還有漏洞。

epoll的兩種模式LT和ET

二者的差異在于level-trigger模式下只要某個socket處于readable/writable狀態(tài)，無論什么時候進(jìn)行epoll_wait都會返回該socket；而edge-trigger模式下只有某個socket從unreadable變?yōu)閞eadable或從unwritable變?yōu)閣ritable時，epoll_wait才會返回該socket。如下兩個示意圖:

從socket讀數(shù)據(jù):

從socket寫數(shù)據(jù):

所以，在epoll的ET模式下，正確的讀寫方式為:

讀：只要可讀，就一直讀，直到返回0，或者 errno = EAGAIN 寫:只要可寫，就一直寫，直到數(shù)據(jù)發(fā)送完，或者 errno = EAGAIN。

正確的讀：

正確的寫：

accept上的問題

• 阻塞模式 accept 存在的問題

考慮這種情況：TCP連接被客戶端夭折，即在服務(wù)器調(diào)用accept之前，客戶端主動發(fā)送RST終止連接，導(dǎo)致剛剛建立的連接從就緒隊列中移出，如果套接口被設(shè)置成阻塞模式，服務(wù)器就會一直阻塞在accept調(diào)用上，直到其他某個客戶建立一個新的連接為止。但是在此期間，服務(wù)器單純地阻塞在accept調(diào)用上，就緒隊列中的其他描述符都得不到處理。

解決方案：把監(jiān)聽套接口設(shè)置為非阻塞，當(dāng)客戶在服務(wù)器調(diào)用accept之前中止某個連接時，accept調(diào)用可以立即返回-1，這時源自Berkeley的實現(xiàn)會在內(nèi)核中處理該事件，并不會將該事件通知給epoll，而其他實現(xiàn)把errno設(shè)置為ECONNABORTED或者EPROTO錯誤，我們應(yīng)該忽略這兩個錯誤。

• ET模式下accept存在的問題。

考慮這種情況：多個連接同時到達(dá)，服務(wù)器的TCP就緒隊列瞬間積累多個就緒連接，由于是邊緣觸發(fā)模式，epoll只會通知一次，accept只處理一個連接，導(dǎo)致TCP就緒隊列中剩下的連接都得不到處理。

解決辦法是用while循環(huán)抱住accept調(diào)用，處理完TCP就緒隊列中的所有連接后再退出循環(huán)。如何知道是否處理完就緒隊列中的所有連接呢？accept返回-1并且errno設(shè)置為EAGAIN就表示所有連接都處理完。

綜合以上兩種情況，服務(wù)器應(yīng)該使用非阻塞地accept，accept在ET模式下的正確使用方式為：

一道騰訊后臺開發(fā)的面試題:

使用Linux epoll模型，水平觸發(fā)模式；當(dāng)socket可寫時，會不停的觸發(fā)socket可寫的事件，如何處理？

第一種最普遍的方式：

需要向socket寫數(shù)據(jù)的時候才把socket加入epoll，等待可寫事件。接受到可寫事件后，調(diào)用write或者send發(fā)送數(shù)據(jù)。當(dāng)所有數(shù)據(jù)都寫完后，把socket移出epoll。

這種方式的缺點是，即使發(fā)送很少的數(shù)據(jù)，也要把socket加入epoll，寫完后在移出epoll，有一定操作代價。

第二種的方式：

開始不把socket加入epoll，需要向socket寫數(shù)據(jù)的時候，直接調(diào)用write或者send發(fā)送數(shù)據(jù)。如果返回EAGAIN，把socket加入epoll，在epoll的驅(qū)動下寫數(shù)據(jù)，全部數(shù)據(jù)發(fā)送完畢后，再移出epoll。這種方式的優(yōu)點是：數(shù)據(jù)不多的時候可以避免epoll的事件處理，提高效率。

我自己代碼的問題

因為我之前才用的是非阻塞ET模式，這樣我在發(fā)送緩沖數(shù)據(jù)的數(shù)據(jù)，會出現(xiàn)EAGAIN的問題。這個問題并不可怕，最可怕的是會發(fā)生，因為上面已經(jīng)有方法解決。為了看起來方便我這邊再拷貝一份。但是我源代碼采用的writev源代碼下載地址614行進(jìn)行發(fā)送，根本無法才采用下面的方法。

我的解決方法采用阻塞寫，這個方法很好的解決上面的問題:對于非阻塞的TCP套接字，如果緩沖區(qū)根本就沒空間，則返回一個EWOULDBLOCK錯誤。如果緩沖區(qū)有一些空間，返回值是內(nèi)核能夠復(fù)制到該緩沖區(qū)的字節(jié)數(shù)。這個字節(jié)數(shù)也叫作不足計數(shù).。詳細(xì)見我上述連接的代碼文件。

在讀取緩沖區(qū)也是這樣。也是采用阻塞進(jìn)行讀取，這樣做，雖然降低并發(fā)性，但是為了準(zhǔn)確處理數(shù)據(jù)。

總結(jié)

ET模式下:

如果read返回0，那么說明已經(jīng)接受所有數(shù)據(jù) 如果errno=EAGAIN，說明還有數(shù)據(jù)未接收，等待下一次通知 如果read返回-1，說明發(fā)生錯誤，停止處理