WINDOWS完成端口編程
1、基本概念
2、WINDOWS完成端口的特點(diǎn)
3、完成端口（Completion Ports ）相關(guān)數據結構和創(chuàng )建
4、完成端口線(xiàn)程的工作原理
5、Windows完成端口的實(shí)例代碼
Linux的EPoll模型
1、為什么select落后
2、內核中提高I/O性能的新方法epoll
3、epoll的優(yōu)點(diǎn)
4、epoll的工作模式
5、epoll的使用方法
6、Linux下EPOll編程實(shí)例
總結
WINDOWS完成端口編程
摘要：開(kāi)發(fā)網(wǎng)絡(luò )程序從來(lái)都不是一件容易的事情，盡管只需要遵守很少的一些規則;創(chuàng )建socket,發(fā)起連接，接受連接，發(fā)送和接受數據。真正的困難在于：讓你的程序可以適應從單單一個(gè)連接到幾千個(gè)連接乃至于上萬(wàn)個(gè)連接。利用Windows平臺完成端口進(jìn)行重疊I/O的技術(shù)和Linux在2.6版本的內核中引入的EPOll技術(shù)，可以很方便在在在Windows和Linux平臺上開(kāi)發(fā)出支持大量連接的網(wǎng)絡(luò )服務(wù)程序。本文介紹在Windows和Linux平臺上使用的完成端口和EPoll模型開(kāi)發(fā)的基本原理，同時(shí)給出實(shí)際的例子。本文主要關(guān)注C/S結構的服務(wù)器端程序，因為一般來(lái)說(shuō)，開(kāi)發(fā)一個(gè)大容量，具可擴展性的winsock程序一般就是指服務(wù)程序。
1、基本概念
設備---windows操作系統上允許通信的任何東西，比如文件、目錄、串行口、并行口、郵件槽、命名管道、無(wú)名管道、套接字、控制臺、邏輯磁盤(pán)、物理磁盤(pán)等。絕大多數與設備打交道的函數都是CreateFile/ReadFile/WriteFile等。所以我們不能看到**File函數就只想到文件設備。與設備通信有兩種方式，同步方式和異步方式。同步方式下，當調用ReadFile函數時(shí)，函數會(huì )等待系統執行完所要求的工作，然后才返回；異步方式下，ReadFile這類(lèi)函數會(huì )直接返回，系統自己去完成對設備的操作，然后以某種方式通知完成操作。
重疊I/O----顧名思義，當你調用了某個(gè)函數（比如ReadFile）就立刻返回做自己的其他動(dòng)作的時(shí)候，同時(shí)系統也在對I/0設備進(jìn)行你要求的操作，在這段時(shí)間內你的程序和系統的內部動(dòng)作是重疊的，因此有更好的性能。所以，重疊I/O是用于異步方式下使用I/O設備的。 重疊I/O需要使用的一個(gè)非常重要的數據結構OVERLAPPED。
2、WINDOWS完成端口的特點(diǎn)
Win32重疊I/O(Overlapped I/O)機制允許發(fā)起一個(gè)操作，然后在操作完成之后接受到信息。對于那種需要很長(cháng)時(shí)間才能完成的操作來(lái)說(shuō)，重疊IO機制尤其有用，因為發(fā)起重疊操作的線(xiàn)程在重疊請求發(fā)出后就可以自由的做別的事情了。在WinNT和Win2000上，提供的真正的可擴展的I/O模型就是使用完成端口（Completion Port）的重疊I/O.完成端口---是一種WINDOWS內核對象。完成端口用于異步方式的重疊I/0情況下，當然重疊I/O不一定非使用完成端口不可，還有設備內核對象、事件對象、告警I/0等。但是完成端口內部提供了線(xiàn)程池的管理，可以避免反復創(chuàng )建線(xiàn)程的開(kāi)銷(xiāo)，同時(shí)可以根據CPU的個(gè)數靈活的決定線(xiàn)程個(gè)數，而且可以讓減少線(xiàn)程調度的次數從而提高性能其實(shí)類(lèi)似于WSAAsyncSelect和select函數的機制更容易兼容Unix，但是難以實(shí)現我們想要的“擴展性”。而且windows的完成端口機制在操作系統內部已經(jīng)作了優(yōu)化，提供了更高的效率。所以，我們選擇完成端口開(kāi)始我們的服務(wù)器程序的開(kāi)發(fā)。
1、發(fā)起操作不一定完成，系統會(huì )在完成的時(shí)候通知你，通過(guò)用戶(hù)在完成端口上的等待，處理操作的結果。所以要有檢查完成端口，取操作結果的線(xiàn)程。在完成端口上守候的線(xiàn)程系統有優(yōu)化，除非在執行的線(xiàn)程阻塞，不會(huì )有新的線(xiàn)程被激活，以此來(lái)減少線(xiàn)程切換造成的性能代價(jià)。所以如果程序中沒(méi)有太多的阻塞操作，沒(méi)有必要啟動(dòng)太多的線(xiàn)程，CPU數量的兩倍，一般這樣來(lái)啟動(dòng)線(xiàn)程。
2、操作與相關(guān)數據的綁定方式：在提交數據的時(shí)候用戶(hù)對數據打相應的標記，記錄操作的類(lèi)型，在用戶(hù)處理操作結果的時(shí)候，通過(guò)檢查自己打的標記和系統的操作結果進(jìn)行相應的處理。
3、操作返回的方式:一般操作完成后要通知程序進(jìn)行后續處理。但寫(xiě)操作可以不通知用戶(hù)，此時(shí)如果用戶(hù)寫(xiě)操作不能馬上完成，寫(xiě)操作的相關(guān)數據會(huì )被暫存到到非交換緩沖區中，在操作完成的時(shí)候，系統會(huì )自動(dòng)釋放緩沖區。此時(shí)發(fā)起完寫(xiě)操作，使用的內存就可以釋放了。此時(shí)如果占用非交換緩沖太多會(huì )使系統停止響應。
3、完成端口（Completion Ports ）相關(guān)數據結構和創(chuàng )建
其實(shí)可以把完成端口看成系統維護的一個(gè)隊列，操作系統把重疊IO操作完成的事件通知放到該隊列里，由于是暴露 “操作完成”的事件通知，所以命名為“完成端口”（COmpletion Ports）。一個(gè)socket被創(chuàng )建后，可以在任何時(shí)刻和一個(gè)完成端口聯(lián)系起來(lái)。
完成端口相關(guān)最重要的是OVERLAPPED數據結構
typedef struct _OVERLAPPED {
ULONG_PTR Internal;//被系統內部賦值，用來(lái)表示系統狀態(tài)
ULONG_PTR InternalHigh;// 被系統內部賦值，傳輸的字節數
union {
struct {
DWORD Offset;//和OffsetHigh合成一個(gè)64位的整數，用來(lái)表示從文件頭部的多少字節開(kāi)始
DWORD OffsetHigh;//操作，如果不是對文件I/O來(lái)操作，則必須設定為0
};
PVOID Pointer;
};
HANDLE hEvent;//如果不使用，就務(wù)必設為0,否則請賦一個(gè)有效的Event句柄
} OVERLAPPED, *LPOVERLAPPED;
下面是異步方式使用ReadFile的一個(gè)例子
OVERLAPPED Overlapped;
Overlapped.Offset=345;
Overlapped.OffsetHigh=0;
Overlapped.hEvent=0;
//假定其他參數都已經(jīng)被初始化
ReadFile(hFile,buffer,sizeof(buffer),&dwNumBytesRead,&Overlapped);
這樣就完成了異步方式讀文件的操作，然后ReadFile函數返回，由操作系統做自己的事情，下面介紹幾個(gè)與OVERLAPPED結構相關(guān)的函數
等待重疊I/0操作完成的函數
BOOL GetOverlappedResult (
HANDLE hFile,
LPOVERLAPPED lpOverlapped,//接受返回的重疊I/0結構
LPDWORD lpcbTransfer,//成功傳輸了多少字節數
BOOL fWait //TRUE只有當操作完成才返回，FALSE直接返回，如果操作沒(méi)有完成，通過(guò)調//用GetLastError ( )函數會(huì )返回ERROR_IO_INCOMPLETE
);
宏HasOverlappedIoCompleted可以幫助我們測試重疊I/0操作是否完成，該宏對OVERLAPPED結構的Internal成員進(jìn)行了測試，查看是否等于STATUS_PENDING值。
一般來(lái)說(shuō)，一個(gè)應用程序可以創(chuàng )建多個(gè)工作線(xiàn)程來(lái)處理完成端口上的通知事件。工作線(xiàn)程的數量依賴(lài)于程序的具體需要。但是在理想的情況下，應該對應一個(gè)CPU創(chuàng )建一個(gè)線(xiàn)程。因為在完成端口理想模型中，每個(gè)線(xiàn)程都可以從系統獲得一個(gè)“原子”性的時(shí)間片，輪番運行并檢查完成端口，線(xiàn)程的切換是額外的開(kāi)銷(xiāo)。在實(shí)際開(kāi)發(fā)的時(shí)候，還要考慮這些線(xiàn)程是否牽涉到其他堵塞操作的情況。如果某線(xiàn)程進(jìn)行堵塞操作，系統則將其掛起，讓別的線(xiàn)程獲得運行時(shí)間。因此，如果有這樣的情況，可以多創(chuàng )建幾個(gè)線(xiàn)程來(lái)盡量利用時(shí)間。
應用完成端口：
創(chuàng )建完成端口：完成端口是一個(gè)內核對象，使用時(shí)他總是要和至少一個(gè)有效的設備句柄進(jìn)行關(guān)聯(lián)，完成端口是一個(gè)復雜的內核對象，創(chuàng )建它的函數是：
HANDLE CreateIoCompletionPort(
IN HANDLE FileHandle,
IN HANDLE ExistingCompletionPort,
IN ULONG_PTR CompletionKey,
IN DWORD NumberOfConcurrentThreads
);
通常創(chuàng )建工作分兩步：
第一步，創(chuàng )建一個(gè)新的完成端口內核對象，可以使用下面的函數：
HANDLE CreateNewCompletionPort(DWORD dwNumberOfThreads)
{
return CreateIoCompletionPort(INVALID_HANDLE_VALUE,NULL,NULL,dwNumberOfThreads);
};
第二步，將剛創(chuàng )建的完成端口和一個(gè)有效的設備句柄關(guān)聯(lián)起來(lái)，可以使用下面的函數：
bool AssicoateDeviceWithCompletionPort(HANDLE hCompPort,HANDLE hDevice,DWORD dwCompKey)
{
HANDLE h=CreateIoCompletionPort(hDevice,hCompPort,dwCompKey,0);
return h==hCompPort;
};
說(shuō)明
1） CreateIoCompletionPort函數也可以一次性的既創(chuàng )建完成端口對象，又關(guān)聯(lián)到一個(gè)有效的設備句柄
2） CompletionKey是一個(gè)可以自己定義的參數，我們可以把一個(gè)結構的地址賦給它，然后在合適的時(shí)候取出來(lái)使用，最好要保證結構里面的內存不是分配在棧上，除非你有十分的把握內存會(huì )保留到你要使用的那一刻。
3） NumberOfConcurrentThreads通常用來(lái)指定要允許同時(shí)運行的的線(xiàn)程的最大個(gè)數。通常我們指定為0，這樣系統會(huì )根據CPU的個(gè)數來(lái)自動(dòng)確定。創(chuàng )建和關(guān)聯(lián)的動(dòng)作完成后，系統會(huì )將完成端口關(guān)聯(lián)的設備句柄、完成鍵作為一條紀錄加入到這個(gè)完成端口的設備列表中。如果你有多個(gè)完成端口，就會(huì )有多個(gè)對應的設備列表。如果設備句柄被關(guān)閉，則表中自動(dòng)刪除該紀錄。
4、完成端口線(xiàn)程的工作原理
完成端口可以幫助我們管理線(xiàn)程池，但是線(xiàn)程池中的線(xiàn)程需要我們使用_beginthreadex來(lái)創(chuàng )建，憑什么通知完成端口管理我們的新線(xiàn)程呢？答案在函數GetQueuedCompletionStatus。該函數原型：
BOOL GetQueuedCompletionStatus(
IN HANDLE CompletionPort,
OUT LPDWORD lpNumberOfBytesTransferred,
OUT PULONG_PTR lpCompletionKey,
OUT LPOVERLAPPED *lpOverlapped,
IN DWORD dwMilliseconds
);
這個(gè)函數試圖從指定的完成端口的I/0完成隊列中抽取紀錄。只有當重疊I/O動(dòng)作完成的時(shí)候，完成隊列中才有紀錄。凡是調用這個(gè)函數的線(xiàn)程將被放入到完成端口的等待線(xiàn)程隊列中，因此完成端口就可以在自己的線(xiàn)程池中幫助我們維護這個(gè)線(xiàn)程。完成端口的I/0完成隊列中存放了當重疊I/0完成的結果---- 一條紀錄，該紀錄擁有四個(gè)字段，前三項就對應GetQueuedCompletionStatus函數的2、3、4參數，最后一個(gè)字段是錯誤信息dwError。我們也可以通過(guò)調用PostQueudCompletionStatus模擬完成了一個(gè)重疊I/0操作。
當I/0完成隊列中出現了紀錄，完成端口將會(huì )檢查等待線(xiàn)程隊列，該隊列中的線(xiàn)程都是通過(guò)調用GetQueuedCompletionStatus函數使自己加入隊列的。等待線(xiàn)程隊列很簡(jiǎn)單，只是保存了這些線(xiàn)程的ID。完成端口會(huì )按照后進(jìn)先出的原則將一個(gè)線(xiàn)程隊列的ID放入到釋放線(xiàn)程列表中，同時(shí)該線(xiàn)程將從等待GetQueuedCompletionStatus函數返回的睡眠狀態(tài)中變?yōu)榭烧{度狀態(tài)等待CPU的調度。所以我們的線(xiàn)程要想成為完成端口管理的線(xiàn)程，就必須要調用GetQueuedCompletionStatus函數。出于性能的優(yōu)化，實(shí)際上完成端口還維護了一個(gè)暫停線(xiàn)程列表，具體細節可以參考《Windows高級編程指南》，我們現在知道的知識，已經(jīng)足夠了。 完成端口線(xiàn)程間數據傳遞線(xiàn)程間傳遞數據最常用的辦法是在_beginthreadex函數中將參數傳遞給線(xiàn)程函數，或者使用全局變量。但是完成端口還有自己的傳遞數據的方法，答案就在于CompletionKey和OVERLAPPED參數。
CompletionKey被保存在完成端口的設備表中，是和設備句柄一一對應的，我們可以將與設備句柄相關(guān)的數據保存到CompletionKey中，或者將CompletionKey表示為結構指針，這樣就可以傳遞更加豐富的內容。這些內容只能在一開(kāi)始關(guān)聯(lián)完成端口和設備句柄的時(shí)候做，因此不能在以后動(dòng)態(tài)改變。
OVERLAPPED參數是在每次調用ReadFile這樣的支持重疊I/0的函數時(shí)傳遞給完成端口的。我們可以看到，如果我們不是對文件設備做操作，該結構的成員變量就對我們幾乎毫無(wú)作用。我們需要附加信息，可以創(chuàng )建自己的結構，然后將OVERLAPPED結構變量作為我們結構變量的第一個(gè)成員，然后傳遞第一個(gè)成員變量的地址給ReadFile函數。因為類(lèi)型匹配，當然可以通過(guò)編譯。當GetQueuedCompletionStatus函數返回時(shí)，我們可以獲取到第一個(gè)成員變量的地址，然后一個(gè)簡(jiǎn)單的強制轉換，我們就可以把它當作完整的自定義結構的指針使用，這樣就可以傳遞很多附加的數據了。太好了！只有一點(diǎn)要注意，如果跨線(xiàn)程傳遞，請注意將數據分配到堆上，并且接收端應該將數據用完后釋放。我們通常需要將ReadFile這樣的異步函數的所需要的緩沖區放到我們自定義的結構中，這樣當GetQueuedCompletionStatus被返回時(shí)，我們的自定義結構的緩沖區變量中就存放了I/0操作的數據。CompletionKey和OVERLAPPED參數，都可以通過(guò)GetQueuedCompletionStatus函數獲得。
線(xiàn)程的安全退出
很多線(xiàn)程為了不止一次的執行異步數據處理，需要使用如下語(yǔ)句
while (true)
{
......
GetQueuedCompletionStatus(...);
......
}
那么如何退出呢，答案就在于上面曾提到的PostQueudCompletionStatus函數，我們可以用它發(fā)送一個(gè)自定義的包含了OVERLAPPED成員變量的結構地址，里面包含一個(gè)狀態(tài)變量，當狀態(tài)變量為退出標志時(shí)，線(xiàn)程就執行清除動(dòng)作然后退出。
5、Windows完成端口的實(shí)例代碼：
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 divpares 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的錯誤），則沒(méi)有任何完成通知時(shí)間會(huì )被放到完成端口隊列里。反之，則一定有相應的通知時(shí)間被放到完成端口隊列。更完善的關(guān)于Winsock的完成端口機制，可以參考MSDN的Microsoft PlatFormSDK，那里有完成端口的例子。訪(fǎng)問(wèn)
http://msdn.microsoft.com/library/techart/msdn_servrapp.htm可以獲得更多信息。
Linux的EPoll模型
Linux 2.6內核中提高網(wǎng)絡(luò )I/O性能的新方法-epoll I/O多路復用技術(shù)在比較多的TCP網(wǎng)絡(luò )服務(wù)器中有使用，即比較多的用到select函數。
1、為什么select落后
首先，在Linux內核中，select所用到的FD_SET是有限的，即內核中有個(gè)參數__FD_SETSIZE定義了每個(gè)FD_SET的句柄個(gè)數，在我用的2.6.15-25-386內核中，該值是1024，搜索內核源代碼得到：
include/linux/posix_types.h:#define __FD_SETSIZE 1024
也就是說(shuō)，如果想要同時(shí)檢測1025個(gè)句柄的可讀狀態(tài)是不可能用select實(shí)現的?；蛘咄瑫r(shí)檢測1025個(gè)句柄的可寫(xiě)狀態(tài)也是不可能的。其次，內核中實(shí)現select是用輪詢(xún)方法，即每次檢測都會(huì )遍歷所有FD_SET中的句柄，顯然，select函數執行時(shí)間與FD_SET中的句柄個(gè)數有一個(gè)比例關(guān)系，即select要檢測的句柄數越多就會(huì )越費時(shí)。當然，在前文中我并沒(méi)有提及poll方法，事實(shí)上用select的朋友一定也試過(guò)poll，我個(gè)人覺(jué)得select和poll大同小異，個(gè)人偏好于用select而已。
2、內核中提高I/O性能的新方法epoll
epoll是什么？按照man手冊的說(shuō)法：是為處理大批量句柄而作了改進(jìn)的poll。要使用epoll只需要這三個(gè)系統調用：epoll_create(2)， epoll_ctl(2)， epoll_wait(2)。
當然，這不是2.6內核才有的，它是在2.5.44內核中被引進(jìn)的(epoll(4) is a new API introduced in Linux kernel 2.5.44)
Linux2.6內核epoll介紹
先介紹2本書(shū)《The Linux Networking Architecture--Design and Implementation of Network Protocols in the Linux Kernel》，以2.4內核講解Linux TCP/IP實(shí)現，相當不錯.作為一個(gè)現實(shí)世界中的實(shí)現，很多時(shí)候你必須作很多權衡，這時(shí)候參考一個(gè)久經(jīng)考驗的系統更有實(shí)際意義。舉個(gè)例子,linux內核中sk_buff結構為了追求速度和安全，犧牲了部分內存，所以在發(fā)送TCP包的時(shí)候，無(wú)論應用層數據多大,sk_buff最小也有272的字節.其實(shí)對于socket應用層程序來(lái)說(shuō)，另外一本書(shū)《UNIX Network Programming Volume 1》意義更大一點(diǎn).2003年的時(shí)候，這本書(shū)出了最新的第3版本，不過(guò)主要還是修訂第2版本。其中第6章《I/O Multiplexing》是最重要的。Stevens給出了網(wǎng)絡(luò )IO的基本模型。在這里最重要的莫過(guò)于select模型和Asynchronous I/O模型.從理論上說(shuō)，AIO似乎是最高效的，你的IO操作可以立即返回，然后等待os告訴你IO操作完成。但是一直以來(lái)，如何實(shí)現就沒(méi)有一個(gè)完美的方案。最著(zhù)名的windows完成端口實(shí)現的AIO,實(shí)際上也是內部用線(xiàn)程池實(shí)現的罷了，最后的結果是IO有個(gè)線(xiàn)程池，你應用也需要一個(gè)線(xiàn)程池...... 很多文檔其實(shí)已經(jīng)指出了這帶來(lái)的線(xiàn)程context-switch帶來(lái)的代價(jià)。在linux 平臺上，關(guān)于網(wǎng)絡(luò )AIO一直是改動(dòng)最多的地方，2.4的年代就有很多AIO內核patch,最著(zhù)名的應該算是SGI那個(gè)。但是一直到2.6內核發(fā)布，網(wǎng)絡(luò )模塊的AIO一直沒(méi)有進(jìn)入穩定內核版本(大部分都是使用用戶(hù)線(xiàn)程模擬方法，在使用了NPTL的linux上面其實(shí)和windows的完成端口基本上差不多了)。2.6內核所支持的AIO特指磁盤(pán)的AIO---支持io_submit(),io_getevents()以及對Direct IO的支持(就是繞過(guò)VFS系統buffer直接寫(xiě)硬盤(pán)，對于流服務(wù)器在內存平穩性上有相當幫助)。
所以，剩下的select模型基本上就是我們在linux上面的唯一選擇，其實(shí)，如果加上no-block socket的配置，可以完成一個(gè)"偽"AIO的實(shí)現，只不過(guò)推動(dòng)力在于你而不是os而已。不過(guò)傳統的select/poll函數有著(zhù)一些無(wú)法忍受的缺點(diǎn)，所以改進(jìn)一直是2.4-2.5開(kāi)發(fā)版本內核的任務(wù)，包括/dev/poll，realtime signal等等。最終，Davide Libenzi開(kāi)發(fā)的epoll進(jìn)入2.6內核成為正式的解決方案
3、epoll的優(yōu)點(diǎn)
<1>支持一個(gè)進(jìn)程打開(kāi)大數目的socket描述符(FD)
select 最不能忍受的是一個(gè)進(jìn)程所打開(kāi)的FD是有一定限制的，由FD_SETSIZE設置，默認值是2048。對于那些需要支持的上萬(wàn)連接數目的IM服務(wù)器來(lái)說(shuō)顯然太少了。這時(shí)候你一是可以選擇修改這個(gè)宏然后重新編譯內核，不過(guò)資料也同時(shí)指出這樣會(huì )帶來(lái)網(wǎng)絡(luò )效率的下降，二是可以選擇多進(jìn)程的解決方案(傳統的Apache方案)，不過(guò)雖然linux上面創(chuàng )建進(jìn)程的代價(jià)比較小，但仍舊是不可忽視的，加上進(jìn)程間數據同步遠比不上線(xiàn)程間同步的高效，所以也不是一種完美的方案。不過(guò) epoll則沒(méi)有這個(gè)限制，它所支持的FD上限是最大可以打開(kāi)文件的數目，這個(gè)數字一般遠大于2048,舉個(gè)例子,在1GB內存的機器上大約是10萬(wàn)左右，具體數目可以cat /proc/sys/fs/file-max察看,一般來(lái)說(shuō)這個(gè)數目和系統內存關(guān)系很大。
<2>IO效率不隨FD數目增加而線(xiàn)性下降
傳統的select/poll另一個(gè)致命弱點(diǎn)就是當你擁有一個(gè)很大的socket集合，不過(guò)由于網(wǎng)絡(luò )延時(shí)，任一時(shí)間只有部分的socket是"活躍"的，但是select/poll每次調用都會(huì )線(xiàn)性?huà)呙枞康募?，導致效率呈現線(xiàn)性下降。但是epoll不存在這個(gè)問(wèn)題，它只會(huì )對"活躍"的socket進(jìn)行操作---這是因為在內核實(shí)現中epoll是根據每個(gè)fd上面的callback函數實(shí)現的。那么，只有"活躍"的socket才會(huì )主動(dòng)的去調用 callback函數，其他idle狀態(tài)socket則不會(huì )，在這點(diǎn)上，epoll實(shí)現了一個(gè)"偽"AIO，因為這時(shí)候推動(dòng)力在os內核。在一些 benchmark中，如果所有的socket基本上都是活躍的---比如一個(gè)高速LAN環(huán)境，epoll并不比select/poll有什么效率，相反，如果過(guò)多使用epoll_ctl,效率相比還有稍微的下降。但是一旦使用idle connections模擬WAN環(huán)境,epoll的效率就遠在select/poll之上了。
<3>使用mmap加速內核與用戶(hù)空間的消息傳遞。
這點(diǎn)實(shí)際上涉及到epoll的具體實(shí)現了。無(wú)論是select,poll還是epoll都需要內核把FD消息通知給用戶(hù)空間，如何避免不必要的內存拷貝就很重要，在這點(diǎn)上，epoll是通過(guò)內核于用戶(hù)空間mmap同一塊內存實(shí)現的。而如果你想我一樣從2.5內核就關(guān)注epoll的話(huà)，一定不會(huì )忘記手工 mmap這一步的。
<4>內核微調
這一點(diǎn)其實(shí)不算epoll的優(yōu)點(diǎn)了，而是整個(gè)linux平臺的優(yōu)點(diǎn)。也許你可以懷疑linux平臺，但是你無(wú)法回避linux平臺賦予你微調內核的能力。比如，內核TCP/IP協(xié)議棧使用內存池管理sk_buff結構，那么可以在運行時(shí)期動(dòng)態(tài)調整這個(gè)內存pool(skb_head_pool)的大小--- 通過(guò)echo XXXX>/proc/sys/net/core/hot_list_length完成。再比如listen函數的第2個(gè)參數(TCP完成3次握手的數據包隊列長(cháng)度)，也可以根據你平臺內存大小動(dòng)態(tài)調整。更甚至在一個(gè)數據包面數目巨大但同時(shí)每個(gè)數據包本身大小卻很小的特殊系統上嘗試最新的NAPI網(wǎng)卡驅動(dòng)架構。
4、epoll的工作模式
令人高興的是，2.6內核的epoll比其2.5開(kāi)發(fā)版本的/dev/epoll簡(jiǎn)潔了許多，所以，大部分情況下，強大的東西往往是簡(jiǎn)單的。唯一有點(diǎn)麻煩是epoll有2種工作方式:LT和ET。
LT(level triggered)是缺省的工作方式，并且同時(shí)支持block和no-block socket.在這種做法中，內核告訴你一個(gè)文件描述符是否就緒了，然后你可以對這個(gè)就緒的fd進(jìn)行IO操作。如果你不作任何操作，內核還是會(huì )繼續通知你的，所以，這種模式編程出錯誤可能性要小一點(diǎn)。傳統的select/poll都是這種模型的代表．
ET (edge-triggered)是高速工作方式，只支持no-block socket。在這種模式下，當描述符從未就緒變?yōu)榫途w時(shí)，內核通過(guò)epoll告訴你。然后它會(huì )假設你知道文件描述符已經(jīng)就緒，并且不會(huì )再為那個(gè)文件描述符發(fā)送更多的就緒通知，直到你做了某些操作導致那個(gè)文件描述符不再為就緒狀態(tài)了(比如，你在發(fā)送，接收或者接收請求，或者發(fā)送接收的數據少于一定量時(shí)導致了一個(gè)EWOULDBLOCK 錯誤）。但是請注意，如果一直不對這個(gè)fd作IO操作(從而導致它再次變成未就緒)，內核不會(huì )發(fā)送更多的通知(only once),不過(guò)在TCP協(xié)議中，ET模式的加速效用仍需要更多的benchmark確認。
epoll只有epoll_create,epoll_ctl,epoll_wait 3個(gè)系統調用，具體用法請參考
http://www.xmailserver.org/linux-patches/nio-improve.html ，在
http://www.kegel.com/rn/也有一個(gè)完整的例子，大家一看就知道如何使用了
Leader/follower模式線(xiàn)程pool實(shí)現，以及和epoll的配合。
5、 epoll的使用方法
首先通過(guò)create_epoll(int maxfds)來(lái)創(chuàng )建一個(gè)epoll的句柄，其中maxfds為你epoll所支持的最大句柄數。這個(gè)函數會(huì )返回一個(gè)新的epoll句柄，之后的所有操作將通過(guò)這個(gè)句柄來(lái)進(jìn)行操作。在用完之后，記得用close()來(lái)關(guān)閉這個(gè)創(chuàng )建出來(lái)的epoll句柄。 之后在你的網(wǎng)絡(luò )主循環(huán)里面，每一幀的調用epoll_wait(int epfd, epoll_event events, int max events, int timeout)來(lái)查詢(xún)所有的網(wǎng)絡(luò )接口，看哪一個(gè)可以讀，哪一個(gè)可以寫(xiě)了?；镜恼Z(yǔ)法為：
nfds = epoll_wait(kdpfd, events, maxevents, -1);
其中kdpfd為用epoll_create創(chuàng )建之后的句柄，events是一個(gè)epoll_event*的指針，當epoll_wait這個(gè)函數操作成功之后，epoll_events里面將儲存所有的讀寫(xiě)事件。max_events是當前需要監聽(tīng)的所有socket句柄數。最后一個(gè)timeout是epoll_wait的超時(shí)，為0的時(shí)候表示馬上返回，為-1的時(shí)候表示一直等下去，直到有事件范圍，為任意正整數的時(shí)候表示等這么長(cháng)的時(shí)間，如果一直沒(méi)有事件，則范圍。一般如果網(wǎng)絡(luò )主循環(huán)是單獨的線(xiàn)程的話(huà)，可以用-1來(lái)等，這樣可以保證一些效率，如果是和主邏輯在同一個(gè)線(xiàn)程的話(huà)，則可以用0來(lái)保證主循環(huán)的效率。
epoll_wait范圍之后應該是一個(gè)循環(huán)，遍利所有的事件：
for(n = 0; n < nfds; ++n) {
if(events[n].data.fd == listener) { //如果是主socket的事件的話(huà)，則表示有新連接進(jìn)入了，進(jìn)行新連接的處理。
client = accept(listener, (struct sockaddr *) &local,
&addrlen);
if(client < 0){
perror("accept");
continue;
}
setnonblocking(client); // 將新連接置于非阻塞模式
ev.events = EPOLLIN | EPOLLET; // 并且將新連接也加入EPOLL的監聽(tīng)隊列。
注意，這里的參數EPOLLIN | EPOLLET并沒(méi)有設置對寫(xiě)socket的監聽(tīng)，如果有寫(xiě)操作的話(huà)，這個(gè)時(shí)候epoll是不會(huì )返回事件的，如果要對寫(xiě)操作也監聽(tīng)的話(huà)，應該是EPOLLIN | EPOLLOUT | EPOLLET
ev.data.fd = client;
if (epoll_ctl(kdpfd, EPOLL_CTL_ADD, client, &ev) < 0) {
// 設置好event之后，將這個(gè)新的event通過(guò)epoll_ctl加入到epoll的監聽(tīng)隊列里面，這里用EPOLL_CTL_ADD來(lái)加一個(gè)新的epoll事件，通過(guò)EPOLL_CTL_DEL來(lái)減少一個(gè)epoll事件，通過(guò)EPOLL_CTL_MOD來(lái)改變一個(gè)事件的監聽(tīng)方式。
fprintf(stderr, "epoll set insertion error: fd=%d0,
client);
return -1;
}
}
else // 如果不是主socket的事件的話(huà)，則代表是一個(gè)用戶(hù)socket的事件，則來(lái)處理這個(gè)用戶(hù)socket的事情，比如說(shuō)read(fd,xxx)之類(lèi)的，或者一些其他的處理。
do_use_fd(events[n].data.fd);
}
對，epoll的操作就這么簡(jiǎn)單，總共不過(guò)4個(gè)API：epoll_create, epoll_ctl, epoll_wait和close。
如果您對epoll的效率還不太了解，請參考我之前關(guān)于網(wǎng)絡(luò )游戲的網(wǎng)絡(luò )編程等相關(guān)的文章。
以前公司的服務(wù)器都是使用HTTP連接，但是這樣的話(huà)，在手機目前的網(wǎng)絡(luò )情況下不但顯得速度較慢，而且不穩定。因此大家一致同意用SOCKET來(lái)進(jìn)行連接。雖然使用SOCKET之后，對于用戶(hù)的費用可能會(huì )增加(由于是用了CMNET而非CMWAP)，但是，秉著(zhù)用戶(hù)體驗至上的原則，相信大家還是能夠接受的(希望那些玩家月末收到帳單不后能夠保持克制...)。
這次的服務(wù)器設計中，最重要的一個(gè)突破，是使用了EPOLL模型，雖然對之也是一知半解，但是既然在各大PC網(wǎng)游中已經(jīng)經(jīng)過(guò)了如此嚴酷的考驗，相信他不會(huì )讓我們失望，使用后的結果，確實(shí)也是表現相當不錯。在這里，我還是主要大致介紹一下這個(gè)模型的結構。
6、Linux下EPOll編程實(shí)例
EPOLL模型似乎只有一種格式，所以大家只要參考我下面的代碼，就能夠對EPOLL有所了解了，代碼的解釋都已經(jīng)在注釋中：
while (TRUE)
{
int nfds = epoll_wait (m_epoll_fd, m_events, MAX_EVENTS, EPOLL_TIME_OUT);//等待EPOLL時(shí)間的發(fā)生，相當于監聽(tīng)，至于相關(guān)的端口，需要在初始化EPOLL的時(shí)候綁定。
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)//如果新監測到一個(gè)HTTP用戶(hù)連接到綁定的HTTP端口，建立新的連接。由于我們新采用了SOCKET連接，所以基本沒(méi)用。
{
OnAcceptHttpEpoll ();
}
else if (m_events[i].data.fd == m_listen_sock_fd)//如果新監測到一個(gè)SOCKET用戶(hù)連接到了綁定的SOCKET端口，建立新的連接。
{
OnAcceptSockEpoll ();
}
else if (m_events[i].events & EPOLLIN)//如果是已經(jīng)連接的用戶(hù)，并且收到數據，那么進(jìn)行讀入。
{
OnReadEpoll (i);
}
OnWriteEpoll (i);//查看當前的活動(dòng)連接是否有需要寫(xiě)出的數據。
}
catch (int)
{
PRINTF ("CATCH捕獲錯誤\n");
continue;
}
}
m_bOnTimeChecking = TRUE;
OnTimer ();//進(jìn)行一些定時(shí)的操作，主要就是刪除一些短線(xiàn)用戶(hù)等。
}
其實(shí)EPOLL的精華，也就是上述的幾段短短的代碼，看來(lái)時(shí)代真的不同了，以前如何接受大量用戶(hù)連接的問(wèn)題，現在卻被如此輕松的搞定，真是讓人不得不感嘆，對哪。
總結
Windows完成端口與Linux epoll技術(shù)方案是這2個(gè)平臺上實(shí)現異步IO和設計開(kāi)發(fā)一個(gè)大容量，具可擴展性的winsock程序指服務(wù)程序的很好的選擇，本文對這2中技術(shù)的實(shí)現原理和實(shí)際的使用方法做了一個(gè)詳細的介紹。
