程式師世界 >> 編程語言 >> C語言 >> C++ >> C++入門知識 >> linux epoll 開發指南-【ffrpc源碼解析】

linux epoll 開發指南-【ffrpc源碼解析】

編輯：C++入門知識

關於epoll的問題很早就像寫文章講講自己的看法，但是由於ffrpc一直沒有完工，所以也就拖下來了。Epoll主要在服務器編程中使用，本文主要探討服務器程序中epoll的使用技巧。Epoll一般和異步io結合使用，故本文討論基於以下應用場合：

主要討論服務器程序中epoll的使用，主要涉及tcp socket的相關api。
Tcp socket 為異步模式，包括socket的異步讀寫，以及監聽的異步操作。
本文不會過多討論API的細節，而是專注流程與設計。

Epoll 的io模型

Epoll是為異步io操作而設計的，epoll中IO事件被分為read事件和write事件，如果大家對於linux的驅動模塊或者linux io 模型有接觸的話，就會理解起來更容易。Linux中IO操作被抽象為read、write、close、ctrl幾個操作，所以epoll只提供read、write、error事件，是和linux的io模型是統一的。

當epoll通知read事件時，可以調用io系統調用read讀取數據
當epoll通知write事件時，可以調用io系統調用write發送數據
當error事件時，可以close回收資源
Ctrl相關的接口則用來設置socket的非阻塞選項等。

為什麼要了解epoll的io模型呢，本文認為，某些情況下epoll操作的代碼的復雜性是由於代碼中的模型（或者類設計）與epoll io模型不匹配造成的。換句話說，如果我們的編碼模型和epoll io模型匹配，那麼非阻塞socket的編碼就會很簡單、清晰。

按照epoll模型構建的類關系為：

typedef  ~ socket_fd_t socket()          =   handle_epoll_read()  =   handle_epoll_write() =   handle_epoll_del()          =   close()                          =  i = , nfds = = (nfds <  && EINTR ===  (i = ; i < nfds; ++& cur_ev =* fd_ptr            = (fd_i* (cur_ev.data.ptr == )
 ( == 
 (cur_ev.events & (EPOLLIN |->(cur_ev.events &-> (cur_ev.events & (EPOLLERR |->(nfds >=

Epoll的LT模式和ET模式的比較

先簡單比較一下level trigger 和 edge trigger 模式的不同。

LT模式的特點是：

若數據可讀，epoll返回可讀事件
若開發者沒有把數據完全讀完，epoll會不斷通知數據可讀，直到數據全部被讀取。
若socket可寫，epoll返回可寫事件，而且是只要socket發送緩沖區未滿，就一直通知可寫事件。
優點是對於read操作比較簡單，只要有read事件就讀，讀多讀少都可以。
缺點是write相關操作較復雜，由於socket在空閒狀態發送緩沖區一定是不滿的，故若socket一直在epoll wait列表中，則epoll會一直通知write事件，所以必須保證沒有數據要發送的時候，要把socket的write事件從epoll wait列表中刪除。而在需要的時候在加入回去，這就是LT模式的最復雜部分。

ET模式的特點是：

若socket可讀，返回可讀事件
若開發者沒有把所有數據讀取完畢，epoll不會再次通知epoll read事件，也就是說存在一種隱患，如果開發者在讀到可讀事件時，如果沒有全部讀取所有數據，那麼可能導致epoll在也不會通知該socket的read事件。（其實這個問題並沒有聽上去難，參見下文）。
若發送緩沖區未滿，epoll通知write事件，直到開發者填滿發送緩沖區，epoll才會在下次發送緩沖區由滿變成未滿時通知write事件。
ET模式下，只有socket的狀態發生變化時才會通知，也就是讀取緩沖區由無數據到有數據時通知read事件，發送緩沖區由滿變成未滿通知write事件。
缺點是epoll read事件觸發時，必須保證socket的讀取緩沖區數據全部讀完（事實上這個要求很容易達到）
優點：對於write事件，發送緩沖區由滿到未滿時才會通知，若無數據可寫，忽略該事件，若有數據可寫，直接寫。Socket的write事件可以一直發在epoll的wait列表。Man epoll中我們知道，當向socket寫數據，返回的值小於傳入的buffer大小或者write系統調用返回EWouldBlock時，表示發送緩沖區已滿。

讓我們換一個角度來理解ET模式，事實上，epoll的ET模式其實就是socket io完全狀態機。

先來看epoll中read 的狀態圖:

當socket由不可讀變成可讀時，epoll的ET模式返回read 事件。對於read 事件，開發者需要保證把讀取緩沖區數據全部讀出，man epoll可知：

Read系統調用返回EwouldBlock，表示讀取緩沖區數據全部讀出
Read系統調用返回的數值小於傳入的buffer參數，表示讀取緩沖區全部讀出。

示例代碼

 nread = = ::read(m_fd, recv_buffer, (recv_buffer) -  (nread > = ->handle_read( (nread < ((recv_buffer) - ;
  ( == nread) 
-> - (errno ==  (errno ==-> -(

再來看write 的狀態機：

需要讀者注意的是，socket模式是可寫的，因為發送緩沖區初始時空的。故應用層有數據要發送時，直接調用write系統調用發送數據，若write系統調用返回EWouldBlock則表示socket變為不可寫，或者write系統調用返回的數值小於傳入的buffer參數的大小，這時需要把未發送的數據暫存在應用層待發送列表中，等待epoll返回write事件，再繼續發送應用層待發送列表中的數據，同樣若應用層待發送列表中的數據沒有一次性發完，那麼繼續等待epoll返回write事件，如此循環往復。所以可以反推得到如下結論，若應用層待發送列表有數據，則該socket一定是不可寫狀態，那麼這時候要發送新數據直接追加到待發送列表中。若待發送列表為空，則表示socket為可寫狀態，則可以直接調用write系統調用發送數據。總結如下：

當發送數據時，若應用層待發送列表有數據，則將要發送的數據追加到待發送列表中。否則直接調用write系統調用。
Write系統調用發送數據時，檢測write返回值，若返回數值>0且小於傳入的buffer參數大小，或返回EWouldBlock錯誤碼，表示，發送緩沖區已滿，將未發送的數據追加到待發送列表
Epoll返回write事件後，檢測待發送列表是否有數據，若有數據，依次嘗試發送指導數據全部發送完畢或者發送緩沖區被填滿。

示例代碼：

 socket_impl_t::send_impl( & buff_ = ( == is_open() || m_sc->check_pre_send(
     ( == ret = (ret <  ->  (ret > 
        m_sc->handle_write_completed( ret =  ( == is_open() ||  ==  & msg == (ret <  -> -  (ret >   ( ==->handle_write_completed(

總結

　　LT模式主要是讀操作比較簡單，但是對於ET模式並沒有優勢，因為將讀取緩沖區數據全部讀出並不是難事。而write操作，ET模式則流程非常的清晰，按照完全狀態機來理解和實現就變得非常容易。而LT模式的write操作則復雜多了，要頻繁的維護epoll的wail列表。

在代碼編寫時，把epoll ET當成狀態機，當socket被創建完成（accept和connect系統調用返回的socket）時加入到epoll列表，之後就不用在從中刪除了。為什麼呢？man epoll中的FAQ告訴我們，當socket被close掉後，其自動從epoll中刪除。對於監聽socket簡單說幾點注意事項：

監聽socket的write事件忽略
監聽socket的read事件表示有新連接，調用accept接受連接，直到返回EWouldBlock。
對於Error事件，有些錯誤是可以接受的錯誤，比如文件描述符用光的錯誤

示例代碼:

=  new_fd = - ((new_fd = ::accept(m_listen_fd, ( sockaddr *)&addr, &addrlen)) == - (errno ==   (errno == EINTR || errno == EMFILE || errno == ECONNABORTED || errno == ENFILE ||== EPERM || errno == ENOBUFS || errno ==);
                m_epoll->mod_fd(  -* socket =-> (

GitHub ：https://github.com/fanchy/FFRPC

ffrpc 介紹: http://www.cnblogs.com/zhiranok/p/ffrpc_summary.html