近期一次面試機會讓我覺得有很多地方理解可能不到位，翻翻谷歌的資料加深對一些技術的理解

五種I/O 模式：
【1】 阻塞 I/O (Linux下的I/O操作默認是阻塞I/O，即open和socket創(chuàng)建的I/O都是阻塞I/O)
【2】 非阻塞 I/O (可以通過fcntl或者open時使用O_NONBLOCK參數(shù)，將fd設置為非阻塞的I/O)
【3】 I/O 多路復用 (I/O多路復用，通常需要非阻塞I/O配合使用)
【4】 信號驅(qū)動 I/O (SIGIO)
【5】 異步 I/O
一般來說，程序進行輸入操作有兩步：
1．等待有數(shù)據(jù)可以讀
2．將數(shù)據(jù)從系統(tǒng)內(nèi)核中拷貝到程序的數(shù)據(jù)區(qū)。
對于sock編程來說:
第一步: 一般來說是等待數(shù)據(jù)從網(wǎng)絡上傳到本地。當數(shù)據(jù)包到達的時候，數(shù)據(jù)將會從網(wǎng)絡層拷貝到內(nèi)核的緩存中；
第二步: 是從內(nèi)核中把數(shù)據(jù)拷貝到程序的數(shù)據(jù)區(qū)中。

阻塞I/O模式 //進程處于阻塞模式時，讓出CPU，進入休眠狀態(tài)
阻塞 I/O 模式是最普遍使用的 I/O 模式。是Linux系統(tǒng)下缺省的IO模式。
大部分程序使用的都是阻塞模式的 I/O 。
一個套接字建立后所處于的模式就是阻塞 I/O 模式。（因為Linux系統(tǒng)默認的IO模式是阻塞模式）

對于一個 UDP 套接字來說，數(shù)據(jù)就緒的標志比較簡單：
（1）已經(jīng)收到了一整個數(shù)據(jù)報
（2）沒有收到。
而 TCP 這個概念就比較復雜，需要附加一些其他的變量。
一個進程調(diào)用 recvfrom ，然后系統(tǒng)調(diào)用并不返回知道有數(shù)據(jù)報到達本地系統(tǒng)，然后系統(tǒng)將數(shù)據(jù)拷貝到進程的緩存中。 （如果系統(tǒng)調(diào)用收到一個中斷信號，則它的調(diào)用會被中斷）
我們稱這個進程在調(diào)用recvfrom一直到從recvfrom返回這段時間是阻塞的。當recvfrom正常返回時，我們的進程繼續(xù)它的操作。

非阻塞模式I/O //非阻塞模式的使用并不普遍，因為非阻塞模式會浪費大量的CPU資源。
當我們將一個套接字設置為非阻塞模式，我們相當于告訴了系統(tǒng)內(nèi)核： “當我請求的I/O 操作不能夠馬上完成，你想讓我的進程進行休眠等待的時候，不要這么做，請馬上返回一個錯誤給我。”
我們開始對 recvfrom 的三次調(diào)用，因為系統(tǒng)還沒有接收到網(wǎng)絡數(shù)據(jù)，所以內(nèi)核馬上返回一個 EWOULDBLOCK的錯誤。
第四次我們調(diào)用 recvfrom 函數(shù)，一個數(shù)據(jù)報已經(jīng)到達了，內(nèi)核將它拷貝到我們的應用程序的緩沖區(qū)中，然后 recvfrom 正常返回，我們就可以對接收到的數(shù)據(jù)進行處理了。
當一個應用程序使用了非阻塞模式的套接字，它需要使用一個循環(huán)來不聽的測試是否一個文件描述符有數(shù)據(jù)可讀(稱做 polling(輪詢))。應用程序不停的 polling 內(nèi)核來檢查是否 I/O操作已經(jīng)就緒。這將是一個極浪費 CPU資源的操作。這種模式使用中不是很普遍。

例如:
對管道的操作，最好使用非阻塞方式！
I/O多路復用 //針對批量IP操作時，使用I/O多路復用，非常有好。
在使用 I/O 多路技術的時候，我們調(diào)用 select()函數(shù)和 poll()函數(shù)或epoll函數(shù)(2.6內(nèi)核開始支持)，在調(diào)用它們的時候阻塞，而不是我們來調(diào)用 recvfrom（或recv）的時候阻塞。
當我們調(diào)用 select函數(shù)阻塞的時候，select 函數(shù)等待數(shù)據(jù)報套接字進入讀就緒狀態(tài)。當select函數(shù)返回的時候， 也就是套接字可以讀取數(shù)據(jù)的時候。 這時候我們就可以調(diào)用 recvfrom函數(shù)來將數(shù)據(jù)拷貝到我們的程序緩沖區(qū)中。
對于單個I/O操作，和阻塞模式相比較，select()和poll()或epoll并沒有什么高級的地方。
而且，在阻塞模式下只需要調(diào)用一個函數(shù)：
讀取或發(fā)送函數(shù)。
在使用了多路復用技術后，我們需要調(diào)用兩個函數(shù)了：
先調(diào)用 select()函數(shù)或poll()函數(shù)，然后才能進行真正的讀寫。

多路復用的高級之處在于::
它能同時等待多個文件描述符，而這些文件描述符（套接字描述符）其中的任意一個進入讀就緒狀態(tài)，select()函數(shù)就可以返回。

IO 多路技術一般在下面這些情況中被使用：
1、當一個客戶端需要同時處理多個文件描述符的輸入輸出操作的時候（一般來說是標準的輸入輸出和網(wǎng)絡套接字)，I/O 多路復用技術將會有機會得到使用。
2、當程序需要同時進行多個套接字的操作的時候。
3、如果一個 TCP 服務器程序同時處理正在偵聽網(wǎng)絡連接的套接字和已經(jīng)連接好的套接字。
4、如果一個服務器程序同時使用 TCP 和 UDP 協(xié)議。
5、如果一個服務器同時使用多種服務并且每種服務可能使用不同的協(xié)議（比如 inetd就是這樣的）。
異步IO模式有::
1、信號驅(qū)動I/O模式
2、異步I/O模式
信號驅(qū)動I/O模式 //自己沒有用過。

我們可以使用信號，讓內(nèi)核在文件描述符就緒的時候使用 SIGIO 信號來通知我們。我們將這種模式稱為信號驅(qū)動 I/O 模式。

為了在一個套接字上使用信號驅(qū)動 I/O 操作，下面這三步是所必須的。
（1）一個和 SIGIO信號的處理函數(shù)必須設定。
（2）套接字的擁有者必須被設定。一般來說是使用 fcntl 函數(shù)的 F_SETOWN 參數(shù)來
進行設定擁有者。
（3）套接字必須被允許使用異步 I/O。一般是通過調(diào)用 fcntl 函數(shù)的 F_SETFL 命令，O_ASYNC為參數(shù)來實現(xiàn)。
雖然設定套接字為異步 I/O 非常簡單，但是使用起來困難的部分是怎樣在程序中斷定產(chǎn)生 SIGIO信號發(fā)送給套接字屬主的時候，程序處在什么狀態(tài)。
1．UDP 套接字的 SIGIO 信號 (比較簡單)
在 UDP 協(xié)議上使用異步 I/O 非常簡單．這個信號將會在這個時候產(chǎn)生：
1、套接字收到了一個數(shù)據(jù)報的數(shù)據(jù)包。
2、套接字發(fā)生了異步錯誤。
當我們在使用 UDP 套接字異步 I/O 的時候，我們使用 recvfrom()函數(shù)來讀取數(shù)據(jù)報數(shù)據(jù)或是異步 I/O 錯誤信息。
2．TCP 套接字的 SIGIO 信號 (不會使用)
不幸的是，異步 I/O 幾乎對 TCP 套接字而言沒有什么作用。因為對于一個 TCP 套接字來說，SIGIO 信號發(fā)生的幾率太高了，所以 SIGIO 信號并不能告訴我們究竟發(fā)生了什么事情。
在 TCP 連接中， SIGIO 信號將會在這個時候產(chǎn)生：
l 在一個監(jiān)聽某個端口的套接字上成功的建立了一個新連接。
l 一個斷線的請求被成功的初始化。
l 一個斷線的請求成功的結束。
l 套接字的某一個通道（發(fā)送通道或是接收通道）被關閉。
l 套接字接收到新數(shù)據(jù)。
l 套接字將數(shù)據(jù)發(fā)送出去。
l 發(fā)生了一個異步 I/O 的錯誤。
一個對信號驅(qū)動 I/O 比較實用的方面是 NTP（網(wǎng)絡時間協(xié)議 Network Time Protocol）服務器，它使用 UDP。這個服務器的主循環(huán)用來接收從客戶端發(fā)送過來的數(shù)據(jù)報數(shù)據(jù)包，然后再發(fā)送請求。對于這個服務器來說，記錄下收到每一個數(shù)據(jù)包的具體時間是很重要的。
因為那將是返回給客戶端的值，客戶端要使用這個數(shù)據(jù)來計算數(shù)據(jù)報在網(wǎng)絡上來回所花費的時間。圖 6-8 表示了怎樣建立這樣的一個 UDP 服務器。

異步I/O模式 //比如寫操作，只需用寫，不一定寫入磁盤(這就是異步I/O)的好處。異步IO的好處效率高。
當我們運行在異步 I/O 模式下時，我們?nèi)绻脒M行 I/O 操作，只需要告訴內(nèi)核我們要進行 I/O 操作，然后內(nèi)核會馬上返回。具體的 I/O 和數(shù)據(jù)的拷貝全部由內(nèi)核來完成，我們的程序可以繼續(xù)向下執(zhí)行。當內(nèi)核完成所有的 I/O 操作和數(shù)據(jù)拷貝后，內(nèi)核將通知我們的程序。
異步 I/O 和 信號驅(qū)動I/O的區(qū)別是：
1、信號驅(qū)動 I/O 模式下，內(nèi)核在操作可以被操作的時候通知給我們的應用程序發(fā)送SIGIO 消息。
2、異步 I/O 模式下，內(nèi)核在所有的操作都已經(jīng)被內(nèi)核操作結束之后才會通知我們的應用程序。
?

=================EPOLL 模型===============================================
Epoll模型詳解
Linux 2.6內(nèi)核中提高網(wǎng)絡I/O性能的新方法-epoll I/O多路復用技術在比較多的TCP網(wǎng)絡服務器中有使用，即比較多的用到select函數(shù)。

1、為什么select落后
首先，在Linux內(nèi)核中，select所用到的FD_SET是有限的，即內(nèi)核中有個參數(shù)__FD_SETSIZE定義了每個FD_SET的句柄個數(shù)，在 我用的2.6.15-25-386內(nèi)核中，該值是1024，搜索內(nèi)核源代碼得到：
include/linux/posix_types.h:
#define __FD_SETSIZE 1024
也就是說，如果想要同時檢測1025個句柄的可讀狀態(tài)是不可能用select實現(xiàn)的。或者 同時檢測1025個句柄的可寫狀態(tài)也是不可能的。其次，內(nèi)核中實現(xiàn) select是用輪詢方法，即每次檢測都會遍歷所有FD_SET中的句柄，顯然，select函數(shù)執(zhí)行時間與FD_SET中的句柄個數(shù)有一個比例關系，即 select要檢測的句柄數(shù)越多就會越費時。當然，在前文中我并沒有提及poll方法，事實上用select的朋友一定也試過poll，我個人覺得 select和poll大同小異，個人偏好于用select而已。

2、內(nèi)核中提高I/O性能的新方法epoll
epoll是什么？按照man手冊的說法：是為處理大批量句柄而作了改進的poll。要使用epoll只需要這三個系統(tǒng)調(diào) 用：epoll_create(2)， epoll_ctl(2)， epoll_wait(2)。
當然，這不是2.6內(nèi)核才有的，它是在 2.5.44內(nèi)核中被引進的(epoll(4) is a new API introduced in Linux kernel 2.5.44)

Linux2.6 內(nèi)核epoll介紹
先介紹2本書《The Linux Networking Architecture–Design and Implementation of Network Protocols in the Linux Kernel》，以2.4內(nèi)核講解Linux TCP/IP實現(xiàn)，相當不錯.作為一個現(xiàn)實世界中的實現(xiàn)，很多時候你必須作很多權衡，這時候參考一個久經(jīng)考驗的系統(tǒng)更有實際意義。舉個例子,linux內(nèi) 核中sk_buff結構為了追求速度和安全，犧牲了部分內(nèi)存，所以在發(fā)送TCP包的時候，無論應用層數(shù)據(jù)多大,sk_buff最小也有272的字節(jié).其實 對于socket應用層程序來說，另外一本書《UNIX Network Programming Volume 1》意義更大一點.2003年的時候，這本書出了最新的第3版本，不過主要還是修訂第2版本。其中第6章《I/O Multiplexing》是最重要的。Stevens給出了網(wǎng)絡IO的基本模型。在這里最重要的莫過于select模型和Asynchronous I/O模型.從理論上說，AIO似乎是最高效的，你的IO操作可以立即返回，然后等待os告訴你IO操作完成。但是一直以來，如何實現(xiàn)就沒有一個完美的方 案。最著名的windows完成端口實現(xiàn)的AIO,實際上也是內(nèi)部用線程池實現(xiàn)的罷了，最后的結果是IO有個線程池，你應用也需要一個線程池…… 很多文檔其實已經(jīng)指出了這帶來的線程context-switch帶來的代價。在linux 平臺上，關于網(wǎng)絡AIO一直是改動最多的地方，2.4的年代就有很多AIO內(nèi)核patch,最著名的應該算是SGI那個。但是一直到2.6內(nèi)核發(fā)布，網(wǎng)絡 模塊的AIO一直沒有進入穩(wěn)定內(nèi)核版本(大部分都是使用用戶線程模擬方法，在使用了NPTL的linux上面其實和windows的完成端口基本上差不多 了)。2.6內(nèi)核所支持的AIO特指磁盤的AIO—支持io_submit(),io_getevents()以及對Direct IO的支持(就是繞過VFS系統(tǒng)buffer直接寫硬盤，對于流服務器在內(nèi)存平穩(wěn)性上有相當幫助)。
所以，剩下的select模型基本上就是我們在linux上面的唯一選擇，其實，如果加上no-block socket的配置，可以完成一個”偽”AIO的實現(xiàn)，只不過推動力在于你而不是os而已。不過傳統(tǒng)的select/poll函數(shù)有著一些無法忍受的缺 點，所以改進一直是2.4-2.5開發(fā)版本內(nèi)核的任務，包括/dev/poll，realtime signal等等。最終，Davide Libenzi開發(fā)的epoll進入2.6內(nèi)核成為正式的解決方案

3、epoll的優(yōu)點
<1>支持一個進程打開大數(shù) 目的socket描述符(FD)
select 最不能忍受的是一個進程所打開的FD是有一定限制的，由FD_SETSIZE設置，默認值是2048。對于那些需要支持的上萬連接數(shù)目的IM服務器來說顯 然太少了。這時候你一是可以選擇修改這個宏然后重新編譯內(nèi)核，不過資料也同時指出這樣會帶來網(wǎng)絡效率的下降，二是可以選擇多進程的解決方案(傳統(tǒng)的 Apache方案)，不過雖然linux上面創(chuàng)建進程的代價比較小，但仍舊是不可忽視的，加上進程間數(shù)據(jù)同步遠比不上線程間同步的高效，所以也不是一種完 美的方案。不過 epoll則沒有這個限制，它所支持的FD上限是最大可以打開文件的數(shù)目，這個數(shù)字一般遠大于2048,舉個例子,在1GB內(nèi)存的機器上大約是10萬左 右，具體數(shù)目可以cat /proc/sys/fs/file-max察看,一般來說這個數(shù)目和系統(tǒng)內(nèi)存關系很大。

<2>IO 效率不隨FD數(shù)目增加而線性下降
傳統(tǒng)的select/poll另一個致命弱點就是當你擁有一個很大的socket集合，不過由于網(wǎng)絡延時，任一時間只有部分的socket是”活躍”的， 但是select/poll每次調(diào)用都會線性掃描全部的集合，導致效率呈現(xiàn)線性下降。但是epoll不存在這個問題，它只會對”活躍”的socket進行 操作—這是因為在內(nèi)核實現(xiàn)中epoll是根據(jù)每個fd上面的callback函數(shù)實現(xiàn)的。那么，只有”活躍”的socket才會主動的去調(diào)用 callback函數(shù)，其他idle狀態(tài)socket則不會，在這點上，epoll實現(xiàn)了一個”偽”AIO，因為這時候推動力在os內(nèi)核。在一些 benchmark中，如果所有的socket基本上都是活躍的—比如一個高速LAN環(huán)境，epoll并不比select/poll有什么效率，相 反，如果過多使用epoll_ctl,效率相比還有稍微的下降。但是一旦使用idle connections模擬WAN環(huán)境,epoll的效率就遠在select/poll之上了。

<3>使用mmap加速內(nèi)核 與用戶空間的消息傳遞。
這點實際上涉及到epoll的具體實現(xiàn)了。無論是select,poll還是epoll都需要內(nèi)核把FD消息通知給用戶空間，如何避免不必要的內(nèi)存拷貝就 很重要，在這點上，epoll是通過內(nèi)核于用戶空間mmap同一塊內(nèi)存實現(xiàn)的。而如果你想我一樣從2.5內(nèi)核就關注epoll的話，一定不會忘記手工 mmap這一步的。

<4>內(nèi)核微調(diào)
這一點其實不算epoll的優(yōu)點了，而是整個linux平臺的優(yōu)點。也許你可以懷疑 linux平臺，但是你無法回避linux平臺賦予你微調(diào)內(nèi)核的能力。比如，內(nèi)核TCP/IP協(xié)議棧使用內(nèi)存池管理sk_buff結構，那么可以在運行時 期動態(tài)調(diào)整這個內(nèi)存pool(skb_head_pool)的大小— 通過echo XXXX>/proc/sys/net/core/hot_list_length完成。再比如listen函數(shù)的第2個參數(shù)(TCP完成3次握手 的數(shù)據(jù)包隊列長度)，也可以根據(jù)你平臺內(nèi)存大小動態(tài)調(diào)整。更甚至在一個數(shù)據(jù)包面數(shù)目巨大但同時每個數(shù)據(jù)包本身大小卻很小的特殊系統(tǒng)上嘗試最新的NAPI網(wǎng) 卡驅(qū)動架構。

4、epoll的工作模式
令人高興的是，2.6內(nèi)核的epoll比其2.5開發(fā)版本的/dev/epoll簡潔了許多，所以，大部分情況下，強大的東西往往是簡單的。唯一有點麻煩 是epoll有2種工作方式:LT和ET。
LT(level triggered)是缺省的工作方式，并且同時支持block和no-block socket.在這種做法中，內(nèi)核告訴你一個文件描述符是否就緒了，然后你可以對這個就緒的fd進行IO操作。如果你不作任何操作，內(nèi)核還是會繼續(xù)通知你 的，所以，這種模式編程出錯誤可能性要小一點。傳統(tǒng)的select/poll都是這種模型的代表．
ET (edge-triggered)是高速工作方式，只支持no-block socket。在這種模式下，當描述符從未就緒變?yōu)榫途w時，內(nèi)核通過epoll告訴你。然后它會假設你知道文件描述符已經(jīng)就緒，并且不會再為那個文件描述 符發(fā)送更多的就緒通知，直到你做了某些操作導致那個文件描述符不再為就緒狀態(tài)了(比如，你在發(fā)送，接收或者接收請求，或者發(fā)送接收的數(shù)據(jù)少于一定量時導致 了一個EWOULDBLOCK 錯誤）。但是請注意，如果一直不對這個fd作IO操作(從而導致它再次變成未就緒)，內(nèi)核不會發(fā)送更多的通知(only once),不過在TCP協(xié)議中，ET模式的加速效用仍需要更多的benchmark確認。
epoll只有epoll_create,epoll_ctl,epoll_wait 3個系統(tǒng)調(diào)用，具體用法請參考http://www.xmailserver.org/linux-patches/nio-improve.html ，在http://www.kegel.com/rn/也有一個完整的例子，大家一看就知道如何使用了
Leader/follower模式線程 pool實現(xiàn)，以及和epoll的配合。

5、 epoll的使用方法
首先通過create_epoll(int maxfds)來創(chuàng)建一個epoll的句柄，其中maxfds為你epoll所支持的最大句柄數(shù)。這個函數(shù)會返回一個新的epoll句柄，之后的所有操作 將通過這個句柄來進行操作。在用完之后，記得用close()來關閉這個創(chuàng)建出來的epoll句柄。之后在你的網(wǎng)絡主循環(huán)里面，每一幀的調(diào)用 epoll_wait(int epfd, epoll_event events, int max events, int timeout)來查詢所有的網(wǎng)絡接口，看哪一個可以讀，哪一個可以寫了。基本的語法為：
nfds = epoll_wait(kdpfd, events, maxevents, -1);
其中kdpfd為用epoll_create創(chuàng)建之后的句柄，events是一個 epoll_event*的指針，當epoll_wait這個函數(shù)操作成功之后，epoll_events里面將儲存所有的讀寫事件。 max_events是當前需要監(jiān)聽的所有socket句柄數(shù)。最后一個timeout是 epoll_wait的超時，為0的時候表示馬上返回，為-1的時候表示一直等下去，直到有事件范圍，為任意正整數(shù)的時候表示等這么長的時間，如果一直沒 有事件，則范圍。一般如果網(wǎng)絡主循環(huán)是單獨的線程的話，可以用-1來等，這樣可以保證一些效率，如果是和主邏輯在同一個線程的話，則可以用0來保證主循環(huán) 的效率。

Epoll模型主要負責對大量并發(fā)用戶的請求進行及時處理，完成服務器與客戶端的數(shù)據(jù)交互。其具體的實現(xiàn)步驟如下：
(a) 使用epoll_create()函數(shù)創(chuàng)建文件描述，設定將可管理的最大socket描述符數(shù)目。
(b) 創(chuàng)建與epoll關聯(lián)的接收線程，應用程序可以創(chuàng)建多個接收線程來處理epoll上的讀通知事件，線程的數(shù)量依賴于程序的具體需要。
(c) 創(chuàng)建一個偵聽socket描述符ListenSock；將該描述符設定為非阻塞模式，調(diào)用Listen（）函數(shù)在套接字上偵聽有無新的連接請求，在 epoll_event結構中設置要處理的事件類型EPOLLIN，工作方式為 epoll_ET，以提高工作效率，同時使用epoll_ctl()注冊事件，最后啟動網(wǎng)絡監(jiān)視線程。
(d) 網(wǎng)絡監(jiān)視線程啟動循環(huán)，epoll_wait()等待epoll事件發(fā)生。
(e) 如果epoll事件表明有新的連接請求，則調(diào)用accept（）函數(shù)，將用戶socket描述符添加到epoll_data聯(lián)合體，同時設定該描述符為非 阻塞，并在epoll_event結構中設置要處理的事件類型為讀和寫，工作方式為epoll_ET.
(f) 如果epoll事件表明socket描述符上有數(shù)據(jù)可讀，則將該socket描述符加入可讀隊列，通知接收線程讀入數(shù)據(jù)，并將接收到的數(shù)據(jù)放入到接收數(shù)據(jù) 的鏈表中，經(jīng)邏輯處理后，將反饋的數(shù)據(jù)包放入到發(fā)送數(shù)據(jù)鏈表中，等待由發(fā)送線程發(fā)送。
C++語言: epoll使用方法101 //epoll_wait范圍之后應該是一個循環(huán)，遍利所有的事件：
02 for (n = 0; n < nfds; ++n)
03 {
04 if (events[n].data.fd == listener)
05 {//如果是主socket的事件的話，則表示有新連接進入了，進行新連接的處理。
06 client = accept (listener, (struct sockaddr *) &local, &addrlen);
07 if (client < 0)
08 {
09 perror ("accept");
10 continue;
11 }
12 setnonblocking (client); // 將新連接置于非阻塞模式
13 ev.events = EPOLLIN | EPOLLET; // 并且將新連接也加入EPOLL的監(jiān)聽隊列。
14 //注意，這里的參數(shù)EPOLLIN | EPOLLET并沒有設置對寫socket的監(jiān)聽，
15 //如果有寫操作的話，這個時候epoll是不會返回事件的，
16 //如果要對寫操作也監(jiān)聽的話，應該是EPOLLIN | EPOLLOUT | EPOLLET
17 ev.data.fd = client;
18 if (epoll_ctl (kdpfd, EPOLL_CTL_ADD, client, &ev) < 0)
19 {
20 /*
21 設置好event之后，將這個新的event通過epoll_ctl加入到epoll的監(jiān)聽隊列里面，
22 這里用EPOLL_CTL_ADD來加一個新的epoll事件,通過EPOLL_CTL_DEL來減少一個epoll事件，通
23 過EPOLL_CTL_MOD來改變一個事件的監(jiān)聽方式.
24 */
25 fprintf (stderr, "epoll set insertion error: fd=%d", client);
26 return -1;
27 }
28 }
29 else // 如果不是主socket的事件的話，則代表是一個用戶socket的事件，
30 do_use_fd (events[n].data.fd); //則來處理這個用戶socket的事情，比如說read(fd,xxx)之類的，或者一些其他的處理。
31 }
對，epoll的操作就這么簡單，總共不過4個 API：epoll_create, epoll_ctl, epoll_wait和close。
如果您對epoll的效率還不太了解，請參考我 之前關于網(wǎng)絡游戲的網(wǎng)絡編程等相關的文章。

以前公司的服務器都是使用HTTP連接，但是這樣的話，在手機目前的網(wǎng)絡情況下不但顯得速度較慢，而且不穩(wěn)定。因此大家一致同意用 SOCKET來進行連接。雖然使用SOCKET之后，對于用戶的費用可能會增加(由于是用了CMNET而非CMWAP)，但是，秉著用戶體驗至上的原則， 相信大家還是能夠接受的(希望那些玩家月末收到帳單不后能夠保持克制...)。
這次的服務器設計中，最重要的一個突破，是使用了EPOLL模型， 雖然對之也是一知半解，但是既然在各大PC網(wǎng)游中已經(jīng)經(jīng)過了如此嚴酷的考驗，相信他不會讓我們失望，使用后的結果，確實也是表現(xiàn)相當不錯。在這里，我還是 主要大致介紹一下這個模型的結構。
6、Linux下EPOll編程實例
EPOLL模型似乎只有一種格式，所以大家只要參考我下面的代碼， 就能夠?qū)POLL有所了解了，代碼的解釋都已經(jīng)在注釋中：

C++語言: Codee#1176301 while (TRUE)
02 {
03 int nfds = epoll_wait (m_epoll_fd, m_events, MAX_EVENTS, EPOLL_TIME_OUT); //等待EPOLL時間的發(fā)生，相當于監(jiān)聽，
04 //至于相關的端口，需要在初始化EPOLL的時候綁定。
05 if (nfds <= 0)
06 continue;
07 m_bOnTimeChecking = FALSE;
08 G_CurTime = time (NULL);
09 for (int i = 0; i < nfds; i++)
10 {
11 try
12 {
13 if (m_events[i].data.fd == m_listen_http_fd) //如果新監(jiān)測到一個HTTP用戶連接到綁定的HTTP端口，
14 //建立新的連接。由于我們新采用了SOCKET連接，所以基本沒用。
15 {
16 OnAcceptHttpEpoll ();
17 }
18 else if (m_events[i].data.fd == m_listen_sock_fd) //如果新監(jiān)測到一個SOCKET用戶連接到了綁定的SOCKET端口，
19 //建立新的連接。
20 {
21 OnAcceptSockEpoll ();
22 }
23 else if (m_events[i].events & EPOLLIN) //如果是已經(jīng)連接的用戶，并且收到數(shù)據(jù)，那么進行讀入。
24 {
25 OnReadEpoll (i);
26 }
27
28 OnWriteEpoll (i); //查看當前的活動連接是否有需要寫出的數(shù)據(jù)。
29 }
30 catch (int)
31 {
32 PRINTF ("CATCH捕獲錯誤\n");
33 continue;
34 }
35 }
36 m_bOnTimeChecking = TRUE;
37 OnTimer (); //進行一些定時的操作，主要就是刪除一些短線用戶等。
38 }

epoll優(yōu)勢 <1>支持一個進程打開大數(shù) 目的socket描述符(FD)
<2>IO 效率不隨FD數(shù)目增加而線性下降
<3>使用mmap加速內(nèi)核 與用戶空間的消息傳遞。
<4>內(nèi)核微調(diào)
工作模式 LT ET 在通知次數(shù)上區(qū)別（重復直到IO操作/只通知一次）

本文出自 指尖起舞，轉(zhuǎn)載時請注明出處及相應鏈接。

本文永久鏈接: http://zacharyhu.org/?p=401

總結

以上是生活随笔為你收集整理的Linux网络编程 五种I/O 模式及select、epoll方法的理解的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。