EPOLL事件之EPOLLRDHUP
在對系統問題進行排查時,我發現了一個奇怪的現象:明明是對方斷開連接,系統卻報告一個查詢失敗的錯誤,但從用戶角度來看請求的結果正常返回,沒有任何問題。
對這個現象深入分析后發現,這是一個基于epoll的連接池實現上的問題,或者說是特性。
首先解釋一下導致這個現象的原因。
在使用epoll時,對端正常斷開連接(調用close()),在服務器端會觸發一個epoll事件。在低于2.6.17版本的內核中,這個epoll事件一般是EPOLLIN,即0x1表示連接可讀。
連接池檢測到某個連接發生EPOLLIN事件且沒有錯誤后,會認為有請求到來,將連接交給上層進行處理。這樣以來,上層嘗試在對端已經close()的連接上讀取請求,只能讀到EOF,會認為發生異常,報告一個錯誤。
因此在使用2.6.17之前版本內核的系統中,我們無法依賴封裝epoll的底層連接庫來實現對對端關閉連接事件的檢測,只能通過上層讀取數據進行區分處理。
因此在使用2.6.7版本內核中增加EPOLLRDHUP事件,表示對端斷開連接,關于添加這個事件的理由可以參見 http://lkml.org/lkml/2003/7/12/116。
?
在使用2.6.17之后版本內核的服務器系統中,對端連接斷開觸發的epoll事件會包含EPOLLIN | EPOLLRDHUP,即0x2001。有了這個事件,對端斷開連接的異常就可以在底層進行處理了,不用再移交到上層。
?
重現這個現象的方法很簡單,首先telent到server,然后什么都不做直接退出,查看在不同系統中觸發的事件碼。
?
注意,在使用2.6.17之前版本內核的系統中,sys/epoll.h的EPOLL_EVENTS枚舉類型中是沒有EPOLLRDHUP事件的,所以帶EPOLLRDHUP的程序無法編譯通過。
總結
以上是生活随笔為你收集整理的EPOLL事件之EPOLLRDHUP的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: Nginx:HTTP框架是如何介入请求
- 下一篇: htop 命令详解