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

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

LT模式

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

ET模式

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

深入理解EPOLLONESHOT事件

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

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

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

小結(jié):

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

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

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

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

epoll的兩種模式LT和ET

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

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

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

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

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

正確的讀：

正確的寫：

accept上的問題

• 阻塞模式 accept 存在的問題

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

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

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

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

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

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

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

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

第一種最普遍的方式：

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

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

第二種的方式：

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

我自己代碼的問題

因?yàn)槲抑安庞玫氖欠亲枞鸈T模式，這樣我在發(fā)送緩沖數(shù)據(jù)的數(shù)據(jù)，會(huì)出現(xiàn)EAGAIN的問題。這個(gè)問題并不可怕，最可怕的是會(huì)發(fā)生，因?yàn)樯厦嬉呀?jīng)有方法解決。為了看起來方便我這邊再拷貝一份。但是我源代碼采用的writev源代碼下載地址614行進(jìn)行發(fā)送，根本無法才采用下面的方法。

我的解決方法采用阻塞寫，這個(gè)方法很好的解決上面的問題:對(duì)于非阻塞的TCP套接字，如果緩沖區(qū)根本就沒空間，則返回一個(gè)EWOULDBLOCK錯(cuò)誤。如果緩沖區(qū)有一些空間，返回值是內(nèi)核能夠復(fù)制到該緩沖區(qū)的字節(jié)數(shù)。這個(gè)字節(jié)數(shù)也叫作不足計(jì)數(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ā)生錯(cuò)誤，停止處理