@peakflys
單線程，壓力測(cè)試流量很大，3K都沒有問題，這時(shí)已經(jīng)受到帶寬限制了。流量小點(diǎn)10K都可以。我們?cè)O(shè)計(jì)只需要1K連接就行了，不夠可以加多個(gè)網(wǎng)關(guān)服，所以綽綽有余了

正因?yàn)橛X得移出epoll隊(duì)列不好，但是不移除也不好，所以et是比較好的方式
代碼其實(shí)相當(dāng)簡(jiǎn)單。

write_list_是應(yīng)用層緩沖區(qū)，在epoll寫事件來的時(shí)候，應(yīng)用層緩沖區(qū)為空的話
設(shè)置socket 可寫。下次往應(yīng)用層緩沖區(qū)寫數(shù)據(jù)時(shí)，檢查socket是否可寫，如果可寫則調(diào)用HandleWrite即可。緩沖區(qū)寫滿的時(shí)候設(shè)置socket不可寫就行了。

HandleWrite有兩個(gè)調(diào)用途徑，一個(gè)是寫事件觸發(fā)，一個(gè)是應(yīng)用層觸發(fā)(socket有is_writable標(biāo)記）。

void HandleWrite()
while (true) {
// 應(yīng)用層緩沖區(qū)全部寫到TCP緩沖區(qū)了, 此時(shí)TCP緩沖區(qū)還是可寫
// et模式下不會(huì)再通知應(yīng)用層, 所以設(shè)置下socket writable狀態(tài)
// 下次應(yīng)用層數(shù)據(jù)來的時(shí)候檢查該狀態(tài)
if (write_list_.TotalSize() == 0) {
socket_.set_is_writable(true);
return;
}
int n = write(fd, write_list_.ReadPoint(), write_list_.readable_size());
const int error_no = errno;
if (n == -1) { // 寫異常
if (error_no == EINTR) {
continue;
}
// 緩沖區(qū)已寫滿, 需要等寫事件
if (error_no == EAGAIN) {
socket_.set_is_writable(false);
return;
} else {
HandleError(error_no);
return;
}
} else { // 寫正常
write_list_.ReadAdvance(n);
}
}

事實(shí)上et要比lt簡(jiǎn)單的多

樓主沒有說到重點(diǎn)，需要注意的是寫事件。
a. 對(duì)于et來說，應(yīng)用層向tcp緩沖區(qū)寫，有可能應(yīng)用層數(shù)據(jù)寫完了，但是tcp緩沖沒有寫到EAGAIN事件，那么此時(shí)需要在應(yīng)用層做個(gè)標(biāo)記，表明tcp緩沖區(qū)是可寫的，否則，由于et是只觸發(fā)一次，應(yīng)用層就再也不會(huì)被通知緩沖區(qū)可寫了。
b. 對(duì)于lt來說，應(yīng)用層確實(shí)會(huì)每次通知可寫事件，問題在于，如果應(yīng)用層沒數(shù)據(jù)需要往Tcp緩沖區(qū)寫的話，epoll還是會(huì)不停的通知你可寫，這時(shí)候需要把描述符移出epoll，避免多次無效的通知
http://www.cnblogs.com/egametang/archive/2012/07/30/2615808.html

我猜你是網(wǎng)易的，呵呵！

一定要糾結(jié)學(xué)術(shù)上的Liskov 替換原則可以設(shè)計(jì)兩個(gè)一模一樣的接口,ConnectionEventHandler和DataEventHandler,兩者成員函數(shù)完全一樣，Acceptor、Connector 分別繼承這兩個(gè)類，這樣也比到處是boost::bind要好，core掉的時(shí)候就不用看著到處的模板目瞪口呆了

不過，既然是一模一樣，順其自然到不如就共用一個(gè)接口類了

@陳碩
Liskov 替換原則是個(gè)過于理想化的原則，實(shí)際使用中需要權(quán)衡

@陳碩
更重要的理由就是：我認(rèn)為這么建模是錯(cuò)的。
Acceptor is-not-a Channel, Acceptor uses a Channel to get readable event notification.
Connector is-not-a Channel, Connector uses a Channel to get writable event notification.

這只是文字上的理解的區(qū)別，既然可以用虛函數(shù)，那必然可以換個(gè)理解,例如：

我們可以這么理解, 把Channel改個(gè)名字EventHandler

Acceptor is a EventHandler
Connector is a EventHandler

@陳碩
為什么不可以？理由？

@陳碩
Channel class設(shè)計(jì)成虛函數(shù)，直接繼承Channel有啥問題？

看過這個(gè)代碼，對(duì)其中一些設(shè)計(jì)很不感冒
例如 channel明明可以設(shè)計(jì)成虛函數(shù)接口，結(jié)果卻硬是用std::function去擼

陳碩估計(jì)老是想著用function了。卻忘記了虛函數(shù)的使用。
例如用boost::bind取代虛函數(shù)這篇文章。一個(gè)對(duì)象級(jí)別的函數(shù)指針當(dāng)然可以取代
類級(jí)別的虛函數(shù)，問題是我需要用大炮打蚊子嗎？類帶一個(gè)函數(shù)指針
與每個(gè)對(duì)象都帶一個(gè)函數(shù)指針，拋開別的不說，就內(nèi)存都要節(jié)省一些。而且用了boost::function調(diào)試起來看到一塊塊模板棧是不是有想死的感覺?

這也算是學(xué)會(huì)用std::function std::bind的一些人的通病了，啥地方都去用std::function。有玩弄技巧之嫌。

說個(gè)搞笑的事情，我們?cè)瓉淼念^自從學(xué)會(huì)用bind這個(gè)東西后，沒有bind就寫不出代碼了……