Windows完成端口與Linux epoll技術簡介 1

時間 2019-11-19

標籤 windows 完成端口 linux epoll 技術簡介欄目 Windows 简体版

原文原文鏈接

Windows完成端口與Linux epoll技術簡介 1
WINDOWS完成端口編程 1
一、基本概念 1
二、WINDOWS完成端口的特色 2
三、完成端口（Completion Ports ）相關數據結構和建立 2
四、完成端口線程的工做原理 4
五、Windows完成端口的實例代碼： 6
Linux的EPoll模型 8
一、爲何select落後 8
二、內核中提升I/O性能的新方法epoll 9
三、epoll的優勢 10
四、epoll的工做模式 10
五、 epoll的使用方法 11
六、Linux下EPOll編程實例 12
總結 14html

WINDOWS完成端口編程linux

摘要：開發網絡程序歷來都不是一件容易的事情，儘管只須要遵照不多的一些規則;建立socket,發起鏈接，接受鏈接，發送和接受數據。真正的困難在於：讓你的程序能夠適應從單單一個鏈接到幾千個鏈接乃至於上萬個鏈接。利用Windows平臺完成端口進行重疊I/O的技術和Linux在2.6版本的內核中引入的EPOll技術，能夠很方便在在在Windows和Linux平臺上開發出支持大量鏈接的網絡服務程序。本文介紹在Windows和Linux平臺上使用的完成端口和EPoll模型開發的基本原理，同時給出實際的例子。本文主要關注C/S結構的服務器端程序，由於通常來講，開發一個大容量，具可擴展性的winsock程序通常就是指服務程序。
一、基本概念
設備---windows操做系統上容許通訊的任何東西，好比文件、目錄、串行口、並行口、郵件槽、命名管道、無名管道、套接字、控制檯、邏輯磁盤、物理磁盤等。絕大多數與設備打交道的函數都是CreateFile/ReadFile/WriteFile等。因此咱們不能看到**File函數就只想到文件設備。與設備通訊有兩種方式，同步方式和異步方式。同步方式下，當調用ReadFile函數時，函數會等待系統執行完所要求的工做，而後才返回；異步方式下，ReadFile這類函數會直接返回，系統本身去完成對設備的操做，而後以某種方式通知完成操做。
重疊I/O----顧名思義，當你調用了某個函數（好比ReadFile）就馬上返回作本身的其餘動做的時候，同時系統也在對I/0設備進行你要求的操做，在這段時間內你的程序和系統的內部動做是重疊的，所以有更好的性能。因此，重疊I/O是用於異步方式下使用I/O設備的。重疊I/O須要使用的一個很是重要的數據結構OVERLAPPED。編程

二、WINDOWS完成端口的特色
win32重疊I/O(Overlapped I/O)機制容許發起一個操做，而後在操做完成以後接受到信息。對於那種須要很長時間才能完成的操做來講，重疊IO機制尤爲有用，由於發起重疊操做的線程在重疊請求發出後就能夠自由的作別的事情了。在WinNT和Win2000上，提供的真正的可擴展的I/O模型就是使用完成端口（Completion Port）的重疊I/O.完成端口---是一種WINDOWS內核對象。完成端口用於異步方式的重疊I/0狀況下，固然重疊I/O不必定非使用完成端口不可，還有設備內核對象、事件對象、告警I/0等。可是完成端口內部提供了線程池的管理，能夠避免反覆建立線程的開銷，同時能夠根據CPU的個數靈活的決定線程個數，並且可讓減小線程調度的次數從而提升性能其實相似於WSAAsyncSelect和select函數的機制更容易兼容Unix，可是難以實現咱們想要的「擴展性」。並且windows的完成端口機制在操做系統內部已經做了優化，提供了更高的效率。因此，咱們選擇完成端口開始咱們的服務器程序的開發。
一、發起操做不必定完成，系統會在完成的時候通知你，經過用戶在完成端口上的等待，處理操做的結果。因此要有檢查完成端口，取操做結果的線程。在完成端口上守候的線程系統有優化，除非在執行的線程阻塞，不會有新的線程被激活，以此來減小線程切換形成的性能代價。因此若是程序中沒有太多的阻塞操做，沒有必要啓動太多的線程，CPU數量的兩倍，通常這樣來啓動線程。

二、操做與相關數據的綁定方式：在提交數據的時候用戶對數據打相應的標記，記錄操做的類型，在用戶處理操做結果的時候，經過檢查本身打的標記和系統的操做結果進行相應的處理。
三、操做返回的方式:通常操做完成後要通知程序進行後續處理。但寫操做能夠不通知用戶，此時若是用戶寫操做不能立刻完成，寫操做的相關數據會被暫存到到非交換緩衝區中，在操做完成的時候，系統會自動釋放緩衝區。此時發起完寫操做，使用的內存就能夠釋放了。此時若是佔用非交換緩衝太多會使系統中止響應。windows

三、完成端口（Completion Ports ）相關數據結構和建立
    其實能夠把完成端口當作系統維護的一個隊列，操做系統把重疊IO操做完成的事件通知放到該隊列裏，因爲是暴露「操做完成」的事件通知，因此命名爲「完成端口」（COmpletion Ports）。一個socket被建立後，能夠在任什麼時候刻和一個完成端口聯繫起來。
完成端口相關最重要的是OVERLAPPED數據結構
typedef struct _OVERLAPPED {
    ULONG_PTR Internal;//被系統內部賦值，用來表示系統狀態
    ULONG_PTR InternalHigh;// 被系統內部賦值，傳輸的字節數
    union {
        struct {
            DWORD Offset;//和OffsetHigh合成一個64位的整數，用來表示從文件頭部的多少字節開始
            DWORD OffsetHigh;//操做，若是不是對文件I/O來操做，則必須設定爲0
        };
        PVOID Pointer;
    };
    HANDLE hEvent;//若是不使用，就務必設爲0,不然請賦一個有效的Event句柄
} OVERLAPPED, *LPOVERLAPPED;

下面是異步方式使用ReadFile的一個例子
OVERLAPPED Overlapped;
Overlapped.Offset=345;
Overlapped.OffsetHigh=0;
Overlapped.hEvent=0;
//假定其餘參數都已經被初始化
ReadFile(hFile,buffer,sizeof(buffer),&dwNumBytesRead,&Overlapped);
這樣就完成了異步方式讀文件的操做，而後ReadFile函數返回，由操做系統作本身的事情，下面介紹幾個與OVERLAPPED結構相關的函數
等待重疊I/0操做完成的函數
BOOL GetOverlappedResult (
HANDLE hFile,
LPOVERLAPPED lpOverlapped,//接受返回的重疊I/0結構
LPDWORD lpcbTransfer,//成功傳輸了多少字節數
BOOL fWait //TRUE只有當操做完成才返回，FALSE直接返回，若是操做沒有完成，經過調//用GetLastError ( )函數會返回ERROR_IO_INCOMPLETE
);
宏HasOverlappedIoCompleted能夠幫助咱們測試重疊I/0操做是否完成，該宏對OVERLAPPED結構的Internal成員進行了測試，查看是否等於STATUS_PENDING值。安全

   通常來講，一個應用程序能夠建立多個工做線程來處理完成端口上的通知事件。工做線程的數量依賴於程序的具體須要。可是在理想的狀況下，應該對應一個CPU建立一個線程。由於在完成端口理想模型中，每一個線程均可以從系統得到一個「原子」性的時間片，輪番運行並檢查完成端口，線程的切換是額外的開銷。在實際開發的時候，還要考慮這些線程是否牽涉到其餘堵塞操做的狀況。若是某線程進行堵塞操做，系統則將其掛起，讓別的線程得到運行時間。所以，若是有這樣的狀況，能夠多建立幾個線程來儘可能利用時間。
應用完成端口：
    建立完成端口：完成端口是一個內核對象，使用時他老是要和至少一個有效的設備句柄進行關聯，完成端口是一個複雜的內核對象，建立它的函數是：
HANDLE CreateIoCompletionPort(
    IN HANDLE FileHandle,
    IN HANDLE ExistingCompletionPort,
    IN ULONG_PTR CompletionKey,
    IN DWORD NumberOfConcurrentThreads
    );

一般建立工做分兩步：
第一步，建立一個新的完成端口內核對象，可使用下面的函數：
       HANDLE CreateNewCompletionPort(DWORD dwNumberOfThreads)
{
          return CreateIoCompletionPort(INVALID_HANDLE_VALUE,NULL,NULL,dwNumberOfThreads);
};

第二步，將剛建立的完成端口和一個有效的設備句柄關聯起來，可使用下面的函數：
       bool AssicoateDeviceWithCompletionPort(HANDLE hCompPort,HANDLE hDevice,DWORD dwCompKey)
{
          HANDLE h=CreateIoCompletionPort(hDevice,hCompPort,dwCompKey,0);
          return h==hCompPort;
};
說明
1） CreateIoCompletionPort函數也能夠一次性的既建立完成端口對象，又關聯到一個有效的設備句柄
2） CompletionKey是一個能夠本身定義的參數，咱們能夠把一個結構的地址賦給它，而後在合適的時候取出來使用，最好要保證結構裏面的內存不是分配在棧上，除非你有十分的把握內存會保留到你要使用的那一刻。
3） NumberOfConcurrentThreads一般用來指定要容許同時運行的的線程的最大個數。一般咱們指定爲0，這樣系統會根據CPU的個數來自動肯定。建立和關聯的動做完成後，系統會將完成端口關聯的設備句柄、完成鍵做爲一條紀錄加入到這個完成端口的設備列表中。若是你有多個完成端口，就會有多個對應的設備列表。若是設備句柄被關閉，則表中自動刪除該紀錄。

四、完成端口線程的工做原理
  完成端口能夠幫助咱們管理線程池，可是線程池中的線程須要咱們使用_beginthreadex來建立，憑什麼通知完成端口管理咱們的新線程呢？答案在函數GetQueuedCompletionStatus。該函數原型：
BOOL GetQueuedCompletionStatus(
    IN HANDLE CompletionPort,
    OUT LPDWORD lpNumberOfBytesTransferred,
    OUT PULONG_PTR lpCompletionKey,
    OUT LPOVERLAPPED *lpOverlapped,
    IN DWORD dwMilliseconds
);
這個函數試圖從指定的完成端口的I/0完成隊列中抽取紀錄。只有當重疊I/O動做完成的時候，完成隊列中才有紀錄。凡是調用這個函數的線程將被放入到完成端口的等待線程隊列中，所以完成端口就能夠在本身的線程池中幫助咱們維護這個線程。完成端口的I/0完成隊列中存放了當重疊I/0完成的結果---- 一條紀錄，該紀錄擁有四個字段，前三項就對應GetQueuedCompletionStatus函數的二、三、4參數，最後一個字段是錯誤信息dwError。咱們也能夠經過調用PostQueudCompletionStatus模擬完成了一個重疊I/0操做。
當I/0完成隊列中出現了紀錄，完成端口將會檢查等待線程隊列，該隊列中的線程都是經過調用GetQueuedCompletionStatus函數使本身加入隊列的。等待線程隊列很簡單，只是保存了這些線程的ID。完成端口會按照後進先出的原則將一個線程隊列的ID放入到釋放線程列表中，同時該線程將從等待GetQueuedCompletionStatus函數返回的睡眠狀態中變爲可調度狀態等待CPU的調度。因此咱們的線程要想成爲完成端口管理的線程，就必需要調用
GetQueuedCompletionStatus函數。出於性能的優化，實際上完成端口還維護了一個暫停線程列表，具體細節能夠參考《Windows高級編程指南》，咱們如今知道的知識，已經足夠了。
完成端口線程間數據傳遞
線程間傳遞數據最經常使用的辦法是在_beginthreadex函數中將參數傳遞給線程函數，或者使用全局變量。可是完成端口還有本身的傳遞數據的方法，答案就在於CompletionKey和OVERLAPPED參數。
CompletionKey被保存在完成端口的設備表中，是和設備句柄一一對應的，咱們能夠將與設備句柄相關的數據保存到CompletionKey中，或者將CompletionKey表示爲結構指針，這樣就能夠傳遞更加豐富的內容。這些內容只能在一開始關聯完成端口和設備句柄的時候作，所以不能在之後動態改變。
OVERLAPPED參數是在每次調用ReadFile這樣的支持重疊I/0的函數時傳遞給完成端口的。咱們能夠看到，若是咱們不是對文件設備作操做，該結構的成員變量就對咱們幾乎毫無做用。咱們須要附加信息，能夠建立本身的結構，而後將OVERLAPPED結構變量做爲咱們結構變量的第一個成員，而後傳遞第一個成員變量的地址給ReadFile函數。由於類型匹配，固然能夠經過編譯。當GetQueuedCompletionStatus函數返回時，咱們能夠獲取到第一個成員變量的地址，而後一個簡單的強制轉換，咱們就能夠把它看成完整的自定義結構的指針使用，這樣就能夠傳遞不少附加的數據了。太好了！只有一點要注意，若是跨線程傳遞，請注意將數據分配到堆上，而且接收端應該將數據用完後釋放。咱們一般須要將ReadFile這樣的異步函數的所須要的緩衝區放到咱們自定義的結構中，這樣當GetQueuedCompletionStatus被返回時，咱們的自定義結構的緩衝區變量中就存放了I/0操做的數據。
CompletionKey和OVERLAPPED參數，均可以經過GetQueuedCompletionStatus函數得到。
線程的安全退出
       不少線程爲了避免止一次的執行異步數據處理，須要使用以下語句
while (true)
{
       .。。。。。。
       GetQueuedCompletionStatus(...);
              。。。。。。
}
那麼如何退出呢，答案就在於上面曾提到的PostQueudCompletionStatus函數，咱們能夠用它發送一個自定義的包含了OVERLAPPED成員變量的結構地址，裏面包含一個狀態變量，當狀態變量爲退出標誌時，線程就執行清除動做而後退出。
五、Windows完成端口的實例代碼：
DWORD WINAPI WorkerThread(LPVOID lpParam)
{
ULONG_PTR *PerHandleKey;
OVERLAPPED *Overlap;
OVERLAPPEDPLUS *OverlapPlus,
*newolp;
DWORD dwBytesXfered;
while (1)
{
ret = GetQueuedCompletionStatus(
hIocp,
&dwBytesXfered,
(PULONG_PTR)&PerHandleKey,
&Overlap,
INFINITE);
if (ret == 0)
{
// Operation failed
continue;
}
OverlapPlus = CONTAINING_RECORD(Overlap, OVERLAPPEDPLUS, ol);
switch (OverlapPlus->OpCode)
{
case OP_ACCEPT:
// Client socket is contained in OverlapPlus.sclient
// Add client to completion port
CreateIoCompletionPort(
(HANDLE)OverlapPlus->sclient,
hIocp,
(ULONG_PTR)0,
0);
// Need a new OVERLAPPEDPLUS structure
// for the newly accepted socket. Perhaps
// keep a look aside list of free structures.
newolp = AllocateOverlappedPlus();
if (!newolp)
{
// Error
}
newolp->s = OverlapPlus->sclient;
newolp->OpCode = OP_READ;
// This function prepares the data to be sent
PrepareSendBuffer(&newolp->wbuf);
ret = WSASend(
newolp->s,
&newolp->wbuf,
1,
&newolp->dwBytes,
0,
&newolp.ol,
NULL);
if (ret == SOCKET_ERROR)
{
if (WSAGetLastError() != WSA_IO_PENDING)
{
// Error
}
}
// Put structure in look aside list for later use
FreeOverlappedPlus(OverlapPlus);
// Signal accept thread to issue another AcceptEx
SetEvent(hAcceptThread);
break;
case OP_READ:
// Process the data read
// Repost the read if necessary, reusing the same
// receive buffer as before
memset(&OverlapPlus->ol, 0, sizeof(OVERLAPPED));
ret = WSARecv(
OverlapPlus->s,
&OverlapPlus->wbuf,
1,
&OverlapPlus->dwBytes,
&OverlapPlus->dwFlags,
&OverlapPlus->ol,
NULL);
if (ret == SOCKET_ERROR)
{
if (WSAGetLastError() != WSA_IO_PENDING)
{
// Error
}
}
break;
case OP_WRITE:
// Process the data sent, etc.
break;
} // switch
} // while
} // WorkerThread服務器

查看以上代碼，注意若是Overlapped操做馬上失敗（好比，返回SOCKET_ERROR或其餘非WSA_IO_PENDING的錯誤），則沒有任何完成通知時間會被放到完成端口隊列裏。反之，則必定有相應的通知時間被放到完成端口隊列。更完善的關於Winsock的完成端口機制，能夠參考MSDN的Microsoft PlatFormSDK，那裏有完成端口的例子。訪問http://msdn.microsoft.com/library/techart/msdn_servrapp.htm能夠得到更多信息。
Linux的EPoll模型網絡

Linux 2.6內核中提升網絡I/O性能的新方法-epollI/O多路複用技術在比較多的TCP網絡服務器中有使用，即比較多的用到select函數。
一、爲何select落後
首先，在Linux內核中，select所用到的FD_SET是有限的，即內核中有個參數__FD_SETSIZE定義了每一個FD_SET的句柄個數，在我用的2.6.15-25-386內核中，該值是1024，搜索內核源代碼獲得：
include/linux/posix_types.h:#define __FD_SETSIZE 1024
也就是說，若是想要同時檢測1025個句柄的可讀狀態是不可能用select實現的。或者同時檢測1025個句柄的可寫狀態也是不可能的。
其次，內核中實現select是用輪詢方法，即每次檢測都會遍歷全部FD_SET中的句柄，顯然，select函數執行時間與FD_SET中的句柄個數有一個比例關係，即select要檢測的句柄數越多就會越費時。
固然，在前文中我並無說起poll方法，事實上用select的朋友必定也試過poll，我我的以爲select和poll大同小異，我的偏好於用select而已。數據結構

二、內核中提升I/O性能的新方法epoll
epoll是什麼？按照man手冊的說法：是爲處理大批量句柄而做了改進的poll。要使用epoll只須要這三個系統調用：epoll_create(2)， epoll_ctl(2)， epoll_wait(2)。
固然，這不是2.6內核纔有的，它是在2.5.44內核中被引進的(epoll(4) is a new API introduced in Linux kernel 2.5.44)多線程

Linux2.6內核epoll介紹
先介紹2本書《The Linux Networking Architecture--Design and Implementation of Network Protocols in the Linux Kernel》，以2.4內核講解Linux TCP/IP實現，至關不錯.做爲一個現實世界中的實現，不少時候你必須做不少權衡，這時候參考一個久經考驗的系統更有實際意義。舉個例子,linux內核中sk_buff結構爲了追求速度和安全，犧牲了部份內存，因此在發送TCP包的時候，不管應用層數據多大,sk_buff最小也有272的字節.其實對於socket應用層程序來講，另一本書《UNIX Network Programming Volume 1》意義更大一點.2003年的時候，這本書出了最新的第3版本，不過主要仍是修訂第2版本。其中第6章《I/O Multiplexing》是最重要的。Stevens給出了網絡IO的基本模型。在這裏最重要的莫過於select模型和Asynchronous I/O模型.從理論上說，AIO彷佛是最高效的，你的IO操做能夠當即返回，而後等待os告訴你IO操做完成。可是一直以來，如何實現就沒有一個完美的方案。最著名的windows完成端口實現的AIO,實際上也是內部用線程池實現的罷了，最後的結果是IO有個線程池，你應用也須要一個線程池...... 不少文檔其實已經指出了這帶來的線程context-switch帶來的代價。在linux 平臺上，關於網絡AIO一直是改動最多的地方，2.4的年代就有不少AIO內核patch,最著名的應該算是SGI那個。可是一直到2.6內核發佈，網絡模塊的AIO一直沒有進入穩定內核版本(大部分都是使用用戶線程模擬方法，在使用了NPTL的linux上面其實和windows的完成端口基本上差很少了)。2.6內核所支持的AIO特指磁盤的AIO---支持io_submit(),io_getevents()以及對Direct IO的支持(就是繞過VFS系統buffer直接寫硬盤，對於流服務器在內存平穩性上有至關幫助)。
因此，剩下的select模型基本上就是咱們在linux上面的惟一選擇，其實，若是加上no-block socket的配置，能夠完成一個"僞"AIO的實現，只不過推進力在於你而不是os而已。不過傳統的select/poll函數有着一些沒法忍受的缺點，因此改進一直是2.4-2.5開發版本內核的任務，包括/dev/poll，realtime signal等等。最終，Davide Libenzi開發的epoll進入2.6內核成爲正式的解決方案
三、epoll的優勢
<1>支持一個進程打開大數目的socket描述符(FD)
select 最不能忍受的是一個進程所打開的FD是有必定限制的，由FD_SETSIZE設置，默認值是2048。對於那些須要支持的上萬鏈接數目的IM服務器來講顯然太少了。這時候你一是能夠選擇修改這個宏而後從新編譯內核，不過資料也同時指出這樣會帶來網絡效率的降低，二是能夠選擇多進程的解決方案(傳統的Apache方案)，不過雖然linux上面建立進程的代價比較小，但仍舊是不可忽視的，加上進程間數據同步遠比不上線程間同步的高效，因此也不是一種完美的方案。不過 epoll則沒有這個限制，它所支持的FD上限是最大能夠打開文件的數目，這個數字通常遠大於2048,舉個例子,在1GB內存的機器上大約是10萬左右，具體數目能夠cat /proc/sys/fs/file-max察看,通常來講這個數目和系統內存關係很大。
<2>IO效率不隨FD數目增長而線性降低
傳統的select/poll另外一個致命弱點就是當你擁有一個很大的socket集合，不過因爲網絡延時，任一時間只有部分的socket是"活躍"的，可是select/poll每次調用都會線性掃描所有的集合，致使效率呈現線性降低。可是epoll不存在這個問題，它只會對"活躍"的socket進行操做---這是由於在內核實現中epoll是根據每一個fd上面的callback函數實現的。那麼，只有"活躍"的socket纔會主動的去調用 callback函數，其餘idle狀態socket則不會，在這點上，epoll實現了一個"僞"AIO，由於這時候推進力在os內核。在一些 benchmark中，若是全部的socket基本上都是活躍的---好比一個高速LAN環境，epoll並不比select/poll有什麼效率，相反，若是過多使用epoll_ctl,效率相比還有稍微的降低。可是一旦使用idle connections模擬WAN環境,epoll的效率就遠在select/poll之上了。
<3>使用mmap加速內核與用戶空間的消息傳遞。
這點實際上涉及到epoll的具體實現了。不管是select,poll仍是epoll都須要內核把FD消息通知給用戶空間，如何避免沒必要要的內存拷貝就很重要，在這點上，epoll是經過內核於用戶空間mmap同一塊內存實現的。而若是你想我同樣從2.5內核就關注epoll的話，必定不會忘記手工 mmap這一步的。
<4>內核微調
這一點其實不算epoll的優勢了，而是整個linux平臺的優勢。也許你能夠懷疑linux平臺，可是你沒法迴避linux平臺賦予你微調內核的能力。好比，內核TCP/IP協議棧使用內存池管理sk_buff結構，那麼能夠在運行時期動態調整這個內存pool(skb_head_pool)的大小--- 經過echo XXXX>/proc/sys/net/core/hot_list_length完成。再好比listen函數的第2個參數(TCP完成3次握手的數據包隊列長度)，也能夠根據你平臺內存大小動態調整。更甚至在一個數據包面數目巨大但同時每一個數據包自己大小卻很小的特殊系統上嘗試最新的NAPI網卡驅動架構。
四、epoll的工做模式
使人高興的是，2.6內核的epoll比其2.5開發版本的/dev/epoll簡潔了許多，因此，大部分狀況下，強大的東西每每是簡單的。惟一有點麻煩是epoll有2種工做方式:LT和ET。
LT(level triggered)是缺省的工做方式，而且同時支持block和no-block socket.在這種作法中，內核告訴你一個文件描述符是否就緒了，而後你能夠對這個就緒的fd進行IO操做。若是你不做任何操做，內核仍是會繼續通知你的，因此，這種模式編程出錯誤可能性要小一點。傳統的select/poll都是這種模型的表明．
ET (edge-triggered)是高速工做方式，只支持no-block socket。在這種模式下，當描述符從未就緒變爲就緒時，內核經過epoll告訴你。而後它會假設你知道文件描述符已經就緒，而且不會再爲那個文件描述符發送更多的就緒通知，直到你作了某些操做致使那個文件描述符再也不爲就緒狀態了(好比，你在發送，接收或者接收請求，或者發送接收的數據少於必定量時致使了一個EWOULDBLOCK 錯誤）。可是請注意，若是一直不對這個fd做IO操做(從而致使它再次變成未就緒)，內核不會發送更多的通知(only once),不過在TCP協議中，ET模式的加速效用仍須要更多的benchmark確認。
epoll只有epoll_create,epoll_ctl,epoll_wait 3個系統調用，具體用法請參考http://www.xmailserver.org/linux-patches/nio-improve.html ，
在http://www.kegel.com/rn/也有一個完整的例子，你們一看就知道如何使用了
Leader/follower模式線程pool實現，以及和epoll的配合架構

五、 epoll的使用方法
首先經過create_epoll(int maxfds)來建立一個epoll的句柄，其中maxfds爲你epoll所支持的最大句柄數。這個函數會返回一個新的epoll句柄，以後的全部操做將經過這個句柄來進行操做。在用完以後，記得用close()來關閉這個建立出來的epoll句柄。以後在你的網絡主循環裏面，每一幀的調用epoll_wait(int epfd, epoll_event events, int max events, int timeout)來查詢全部的網絡接口，看哪個能夠讀，哪個能夠寫了。基本的語法爲：
nfds = epoll_wait(kdpfd, events, maxevents, -1);
其中kdpfd爲用epoll_create建立以後的句柄，events是一個epoll_event*的指針，當epoll_wait這個函數操做成功以後，epoll_events裏面將儲存全部的讀寫事件。max_events是當前須要監聽的全部socket句柄數。最後一個timeout是epoll_wait的超時，爲0的時候表示立刻返回，爲-1的時候表示一直等下去，直到有事件範圍，爲任意正整數的時候表示等這麼長的時間，若是一直沒有事件，則範圍。通常若是網絡主循環是單獨的線程的話，能夠用-1來等，這樣能夠保證一些效率，若是是和主邏輯在同一個線程的話，則能夠用0來保證主循環的效率。

epoll_wait範圍以後應該是一個循環，遍利全部的事件：
for(n = 0; n < nfds; ++n) {
               if(events[n].data.fd == listener) { //若是是主socket的事件的話，則表示有新鏈接進入了，進行新鏈接的處理。
                   client = accept(listener, (struct sockaddr *) &local,
                                   &addrlen);
                   if(client < 0){
                       perror("accept");
                       continue;
                   }
                   setnonblocking(client); // 將新鏈接置於非阻塞模式
                   ev.events = EPOLLIN | EPOLLET; // 而且將新鏈接也加入EPOLL的監聽隊列。
注意，這裏的參數EPOLLIN | EPOLLET並無設置對寫socket的監聽，若是有寫操做的話，這個時候epoll是不會返回事件的，若是要對寫操做也監聽的話，應該是EPOLLIN | EPOLLOUT | EPOLLET
                   ev.data.fd = client;
                   if (epoll_ctl(kdpfd, EPOLL_CTL_ADD, client, &ev) < 0) {
// 設置好event以後，將這個新的event經過epoll_ctl加入到epoll的監聽隊列裏面，這裏用EPOLL_CTL_ADD來加一個新的epoll事件，經過EPOLL_CTL_DEL來減小一個epoll事件，經過EPOLL_CTL_MOD來改變一個事件的監聽方式。
                       fprintf(stderr, "epoll set insertion error: fd=%d0,
                               client);
                       return -1;
                   }
               }
               else // 若是不是主socket的事件的話，則表明是一個用戶socket的事件，則來處理這個用戶socket的事情，好比說read(fd,xxx)之類的，或者一些其餘的處理。
                   do_use_fd(events[n].data.fd);
}

對，epoll的操做就這麼簡單，總共不過4個API：epoll_create, epoll_ctl, epoll_wait和close。
若是您對epoll的效率還不太瞭解，請參考我以前關於網絡遊戲的網絡編程等相關的文章。

之前公司的服務器都是使用HTTP鏈接，可是這樣的話，在手機目前的網絡狀況下不但顯得速度較慢，並且不穩定。所以你們一致贊成用SOCKET來進行鏈接。雖然使用SOCKET以後，對於用戶的費用可能會增長(因爲是用了CMNET而非CMWAP)，可是，秉着用戶體驗至上的原則，相信你們仍是可以接受的(但願那些玩家月末收到賬單不後可以保持克制...)。
此次的服務器設計中，最重要的一個突破，是使用了EPOLL模型，雖然對之也是隻知其一;不知其二，可是既然在各大PC網遊中已經通過了如此嚴酷的考驗，相信他不會讓咱們失望，使用後的結果，確實也是表現至關不錯。在這裏，我仍是主要大體介紹一下這個模型的結構。
六、Linux下EPOll編程實例
EPOLL模型彷佛只有一種格式，因此你們只要參考我下面的代碼，就可以對EPOLL有所瞭解了，代碼的解釋都已經在註釋中：

while (TRUE)
{
int nfds = epoll_wait (m_epoll_fd, m_events, MAX_EVENTS, EPOLL_TIME_OUT);//等待EPOLL時間的發生，至關於監聽，至於相關的端口，須要在初始化EPOLL的時候綁定。
if (nfds <= 0)
continue;
m_bOnTimeChecking = FALSE;
G_CurTime = time(NULL);
for (int i=0; i
{
try
{
if (m_events[i].data.fd == m_listen_http_fd)//若是新監測到一個HTTP用戶鏈接到綁定的HTTP端口，創建新的鏈接。因爲咱們新採用了SOCKET鏈接，因此基本沒用。
{
OnAcceptHttpEpoll ();
}
else if (m_events[i].data.fd == m_listen_sock_fd)//若是新監測到一個SOCKET用戶鏈接到了綁定的SOCKET端口，創建新的鏈接。
{
OnAcceptSockEpoll ();
}
else if (m_events[i].events & EPOLLIN)//若是是已經鏈接的用戶，而且收到數據，那麼進行讀入。
{
OnReadEpoll (i);
}

OnWriteEpoll (i);//查看當前的活動鏈接是否有須要寫出的數據。
}
catch (int)
{
PRINTF ("CATCH捕獲錯誤\n");
continue;
}
}
m_bOnTimeChecking = TRUE;
OnTimer ();//進行一些定時的操做，主要就是刪除一些短線用戶等。
}
其實EPOLL的精華，也就是上述的幾段短短的代碼，看來時代真的不一樣了，之前如何接受大量用戶鏈接的問題，如今卻被如此輕鬆的搞定，真是讓人不得不感嘆，對哪。

總結 Windows完成端口與Linux epoll技術方案是這2個平臺上實現異步IO和設計開發一個大容量，具可擴展性的winsock程序指服務程序的很好的選擇，本文對這2中技術的實現原理和實際的使用方法作了一個詳細的介紹。