## poll觸發模式： * ET（邊緣模式） * LT（水平模式） ### LT模式 是標準模式，意味著每次epoll\_wait()返回后，事件處理后，如果之后還有數據，會不斷觸發，也就是說，一個套接字上一次完整的數據，epoll\_wait()可能會返回多次，直到沒有數據為止。 ### ET模式 也稱高效模式，有數據過來后，epoll\_wait()會返回一次，一段時間內，該套接字就算有數據源源不斷地過來，epoll\_wait()也不會返回了。這里注意，是一段時間，不代表這個套接字上有數據就只觸發一次。時間過長，還是會返回多次的。比如我寫FTP用了epoll+多線程，但是每次套接字上有信息就開線程處理，同一時間內希望一個套接字只被一個線程持有，但是因為文件傳輸時間過長，就算使用ET模式，套接字還是會返回多次。這里要特別強調一個參數EPOLLONESHOT，如果要保證套接字同一時段只被一個線程處理，必須加上。 解決方案：給accept()后的套接字加上參數EPOLLONESHOT，線程結束后處理完之后，再重置EPOLLONESHOT屬性，但是，千萬不可以給listen()后的監聽套接字設置此屬性，這會造成同一時刻只能處理一個連接的情況。 ### ET模式下，正確的讀寫方式為: 讀 ：只要可讀，就一直讀，直到返回0，或者 errno = EAGAIN 寫 : 只要可寫，就一直寫，直到數據發送完，或者 errno = EAGAIN。 ***** ### 深入理解EPOLLONESHOT事件 即使使用ET模式，一個socket上的某個事件還是可能被觸發多次，這是跟數據報的大小有關系，常見的情景就是一個線程，而在數據的處理過程中該socket上又有新數據可讀（EPOLLIN再次被觸發），此時另外一個線程被喚醒處理這些新的數據，于是出現了兩個線程同時操作一個socket，為了避免這種情況，就可以采用epoll的EPOLLONESPOT事件。同時要注意，注冊了EPOLLONESHOT事件的socket一旦被某個線程處理完畢，該線程就應該立即重置這個socket的EPOLLONESHOT的事件，以確保這個socket下次可讀時，其EPOLLIN事件被觸發，進而讓其他的工作線程有機會繼續處理這個socket。 ***** ### 網絡事件EAGIN 在一個非阻塞的socket上調用read/write函數, 返回EAGAIN或者EWOULDBLOCK(注: EAGAIN就是EWOULDBLOCK)從字面上看, 意思是:EAGAIN: 再試一次，EWOULDBLOCK: 如果這是一個阻塞socket, 操作將被block，perror輸出: Resource temporarily unavailable. **小結:** 這個錯誤表示資源暫時不夠，能read時，讀緩沖區沒有數據，或者write時，寫緩沖區滿了。遇到這種情況， 如果是阻塞socket，read/write就要阻塞掉。 如果是非阻塞socket，read/write立即返回-1， 同時errno設置為EAGAIN。 所以，對于阻塞socket，read/write返回-1代表網絡出錯了。但對于非阻塞socket，read/write返回-1不一定網絡真的出錯了。可能是Resource temporarily unavailable。這時你應該再試，直到Resource available。 > EAGAIN: 再試一次，EWOULDBLOCK: 如果這是一個阻塞socket, 操作將被block，perror輸出: Resource temporarily unavailable。這個錯誤表示資源暫時不夠，能read時，讀緩沖區沒有數據，或者write時，寫緩沖區滿了。遇到這種情況，如果是阻塞socket，read/write就要阻塞掉。而如果是非阻塞socket，read/write立即返回-1， 同時errno設置為EAGAIN。所以，對于阻塞socket，read/write返回-1代表網絡出錯了。但對于非阻塞socket，read/write返回-1不一定網絡真的出錯了。可能是Resource temporarily unavailable。這時你應該再試，直到Resource available。 綜上，對于non-blocking的socket，正確的讀寫操作為: **讀** : 忽略掉errno = EAGAIN的錯誤，下次繼續讀 **寫** " 忽略掉errno = EAGAIN的錯誤，下次繼續寫 **對于select和epoll的LT模式，這種讀寫方式是沒有問題的。但對于epoll的ET模式，這種方式還有漏洞。** 正確的讀： ``` n = 0; while ((nread = read(fd, buf + n, BUFSIZ-1)) > 0) { if (nread == -1 && errno != EAGAIN) { perror("read error"); } n += nread; } ``` 正確的寫： ``` int nwrite, data\_size = strlen(buf); n = data\_size; while (n > 0) { nwrite = write(fd, buf + data\_size - n, n); if (nwrite < n) { if (nwrite == -1 && errno != EAGAIN) { perror("write error"); } break; } n -= nwrite; } ``` ## accept上的問題 ### 阻塞模式 accept 存在的問題 考慮這種情況：TCP連接被客戶端夭折，即在服務器調用accept之前，客戶端主動發送RST終止連接，導致剛剛建立的連接從就緒隊列中移出，如果套接口被設置成阻塞模式，服務器就會一直阻塞在accept調用上，直到其他某個客戶建立一個新的連接為止。但是在此期間，服務器單純地阻塞在accept調用上，就緒隊列中的其他描述符都得不到處理。 **解決方案：** 把監聽套接口設置為非阻塞，當客戶在服務器調用accept之前中止某個連接時，accept調用可以立即返回-1，這時源自Berkeley的實現會在內核中處理該事件，并不會將該事件通知給epoll，而其他實現把errno設置為ECONNABORTED或者EPROTO錯誤，我們應該忽略這兩個錯誤。 ### ET模式下accept存在的問題。 考慮這種情況：多個連接同時到達，服務器的TCP就緒隊列瞬間積累多個就緒連接，由于是邊緣觸發模式，epoll只會通知一次，accept只處理一個連接，導致TCP就緒隊列中剩下的連接都得不到處理。 解決辦法是用while循環抱住accept調用，處理完TCP就緒隊列中的所有連接后再退出循環。如何知道是否處理完就緒隊列中的所有連接呢？accept返回-1并且errno設置為EAGAIN就表示所有連接都處理完。 綜合以上兩種情況，服務器應該使用非阻塞地accept，accept在ET模式下的正確使用方式為： ``` while ((conn_sock = accept(listenfd,(struct sockaddr *) &remote, (size_t *)&addrlen)) > 0) { handle_client(conn_sock); } if (conn_sock == -1) { if (errno != EAGAIN && errno != ECONNABORTED && errno != EPROTO && errno != EINTR) perror("accept"); } ``` ### 一道騰訊后臺開發的面試題: 使用Linux epoll模型，水平觸發模式；當socket可寫時，會不停的觸發socket可寫的事件，如何處理？ \+ 第一種最普遍的方式： 需要向socket寫數據的時候才把socket加入epoll，等待可寫事件。接受到可寫事件后，調用write或者send發送數據。當所有數據都寫完后，把socket移出epoll。 這種方式的缺點是，即使發送很少的數據，也要把socket加入epoll，寫完后在移出epoll，有一定操作代價。 * 第二種的方式： 開始不把socket加入epoll，需要向socket寫數據的時候，直接調用write或者send發送數據。如果返回EAGAIN，把socket加入epoll，在epoll的驅動下寫數據，全部數據發送完畢后，再移出epoll。 這種方式的優點是：數據不多的時候可以避免epoll的事件處理，提高效率。 我自己代碼的問題 因為我之前才用的是非阻塞ET模式，這樣我在發送緩沖數據的數據，會出現EAGAIN的問題。這個問題并不可怕，最可怕的是會發生，因為上面已經有方法解決。為了看起來方便我這邊再拷貝一份。但是我源代碼采用的writev[源代碼下載地址614行](https://github.com/youbingchenyoubing/cachePool/blob/master/src/entrance.cpp)進行發送，根本無法才采用下面的方法。 ``` ~~~ int nwrite, data_size = strlen(buf); n = data_size; while (n > 0) { nwrite = write(fd, buf + data_size - n, n); if (nwrite < n) { if (nwrite == -1 && errno != EAGAIN) { perror("write error"); } break; } n -= nwrite; } ~~~ ``` 我的解決方法采用阻塞寫，這個方法很好的解決上面的問題:對于非阻塞的TCP套接字，如果緩沖區根本就沒空間，則返回一個EWOULDBLOCK錯誤。如果緩沖區有一些空間，返回值是內核能夠復制到該緩沖區的字節數。這個字節數也叫作不足計數.。詳細見我上述連接的代碼文件。 在讀取緩沖區也是這樣。也是采用阻塞進行讀取，這樣做，雖然降低并發性，但是為了準確處理數據。 總結 **ET模式下:** 如果read返回0，那么說明已經接受所有數據 如果errno=EAGAIN，說明還有數據未接收，等待下一次通知 如果read返回-1，說明發生錯誤，停止處理