epoll有兩種模式,edge triggered(簡稱et) 和 level triggered(簡稱lt).在採用這兩種模式時要注意的是,如果採用et模式,那麼僅當狀態發生變化時才會通知,而採用lt模式類似於原來的select/poll操作,只要還有沒有處理的事件就會一直通知.
以**來說明問題:
首先給出server的**,需要說明的是每次accept的連線,加入可讀集的時候採用的都是et模式,而且接收緩衝區是5位元組的,也就是每次只接收5位元組的資料:
#include
<
iostream
>
#include
<
sys/
socket.h
>
#include
<
sys/
epoll.h
>
#include
<
netinet
/in.h
>
#include
<
arpa
/inet.h
>
#include
<
fcntl.h
>
#include
<
unistd.h
>
#include
<
stdio.h
>
#include
<
errno.h
>
using namespace std;
#define maxline
5#define open_max
100#define listenq
20#define serv_port
5000
#define inftim
1000
void setnonblocking(
intsock)
opts
=opts|o_nonblock;
if(fcntl(sock,f_setfl,opts)
<0)
}intmain()
//setnonblocking(connfd);
char
*str
=inet_ntoa(clientaddr.sin_addr);
cout
<<
"accapt a connection from
"<<
str
<<
endl;
//設定用於讀操作的檔案描述符
ev.data.fd
=connfd;
//設定用於注測的讀操作事件
ev.events
=epollin|epollet;
=epollin;
//註冊ev
epoll_ctl(epfd,epoll_ctl_add,connfd,
&ev);
}else
if(events[i].events
&epollin)
else
std::cout
<<
"readline error
"<<
std::endl;
} else
if(n ==0
) line[n] ='
/0';
cout
<<
"read
"<<
line
<<
endl;
//設定用於寫操作的檔案描述符
ev.data.fd
=sockfd;
//設定用於注測的寫操作事件
ev.events
=epollout|epollet;
//修改sockfd上要處理的事件為epollout
//epoll_ctl(epfd,epoll_ctl_mod,sockfd,
&ev);
}else
if(events[i].events
&epollout)}}
return 0;
} 下面給出測試所用的perl寫的client端,在client中傳送10位元組的資料,同時讓client在傳送完資料之後進入死迴圈, 也就是在傳送完之後連線的狀態不發生改變--既不再傳送資料, 也不關閉連線,這樣才能觀察出server的狀態: #!
/usr
/bin
/perl
use io::socket;
my $host ="
127.0.0.1";
my $port
=5000
;my $socket
=io::socket::inet
->
new(
"$host:$port")
ordie
"create socket error $@";
my $msg_out ="
1234567890";
print $socket $msg_out;
"now send over, go to sleep
while(1
) 執行server和client發現,server僅僅讀取了5位元組的資料,而client其實傳送了10位元組的資料,也就是說,server僅當第一次監聽到了epollin事件,由於沒有讀取完資料,而且採用的是et模式,狀態在此之後不發生變化,因此server再也接收不到epollin事件了.
如果我們把client改為這樣: #!
/usr
/bin
/perl
use io::socket;
my $host ="
127.0.0.1";
my $port
=5000
;my $socket
=io::socket::inet
->
new(
"$host:$port")
ordie
"create socket error $@";
my $msg_out ="
1234567890";
print $socket $msg_out;
"now send over, go to sleep
sleep(5);
"5 second gone
print $socket $msg_out;
while(1
) 可以發現,在server接收完5位元組的資料之後一直監聽不到client的事件,而當client休眠5秒之後重新傳送資料,server再次監聽到了變化,只不過因為只是讀取了5個位元組,仍然有10個位元組的資料(client第二次傳送的資料)沒有接收完.
如果上面的實驗中,對accept的socket都採用的是lt模式,那麼只要還有資料留在buffer中,server就會繼續得到通知,讀者可以自行改動**進行實驗.
基於這兩個實驗,可以得出這樣的結論:et模式僅當狀態發生變化的時候才獲得通知,這裡所謂的狀態的變化並不包括緩衝區中還有未處理的資料,也就是說,如果要採用et模式,需要一直read/write直到出錯為止,很多人反映為什麼採用et模式只接收了一部分資料就再也得不到通知了,大多因為這樣;而lt模式是只要有資料沒有處理就會一直通知下去的.
補充說明一下這裡一直強調的"狀態變化"是什麼:
1)對於監聽可讀事件時,如果是socket是監聽socket,那麼當有新的主動連線到來為狀態發生變化;對一般的socket而言,協議棧中相應的緩衝區有新的資料為狀態發生變化.但是,如果在乙個時間同時接收了n個連線(n>1),但是監聽socket只accept了乙個連線,那麼其它未 accept的連線將不會在et模式下給監聽socket發出通知,此時狀態不發生變化;對於一般的socket,就如例子中而言,如果對應的緩衝區本身已經有了n位元組的資料,而只取出了小於n位元組的資料,那麼殘存的資料不會造成狀態發生變化.
2)對於監聽可寫事件時,同理可推,不再詳述.
而不論是監聽可讀還是可寫,對方關閉socket連線都將造成狀態發生變化,比如在例子中,如果強行中斷client指令碼,也就是主動中斷了socket連線,那麼都將造成server端發生狀態的變化,從而server得到通知,將已經在本方緩衝區中的資料讀出.
把前面的描述可以總結如下:僅當對方的動作(發出資料,關閉連線等)造成的事件才能導致狀態發生變化,而本方協議棧中已經處理的事件(包括接收了對方的資料,接收了對方的主動連線請求)並不是造成狀態發生變化的必要條件,狀態變化一定是對方造成的.所以在et模式下的,必須一直處理到出錯或者完全處理完畢,才能進行下乙個動作,否則可能會發生錯誤.
另外,從這個例子中,也可以闡述一些基本的網路程式設計概念.首先,連線的兩端中,一端傳送成功並不代表著對方上層應用程式接收成功, 就拿上面的client測試程式來說,10位元組的資料已經傳送成功,但是上層的server並沒有呼叫read讀取資料,因此傳送成功僅僅說明了資料被對方的協議棧接收存放在了相應的buffer中,而上層的應用程式是否接收了這部分資料不得而知;同樣的,讀取資料時也只代表著本方協議棧的對應buffer中有資料可讀,而此時時候在對端是否在傳送資料也不得而知.
**：
epoll 學習筆記
epoll有兩種模式,edge triggered 簡稱et 和 level triggered 簡稱lt 在採用這兩種模式時要注意的是,如果採用et模式,那麼僅當狀態發生變化時才會通知,而採用lt模式類似於原來的 select poll操作,只要還有沒有處理的事件就會一直通知.以 來說明問題 首先...
epoll學習筆記
epoll學習筆記 epoll有兩種模式,edge triggered 簡稱et 和 level triggered 簡稱lt 在採用這兩種模式時要注意的是,如果採用et模式,那麼僅當狀態發生變化時才會通知,而採用lt模式類似於原來的select poll操作,只要還有沒有處理的事件就會一直通知.以...
epoll學習筆記
epoll有兩種模式,edge triggered 簡稱et 和 level triggered 簡稱lt 在採用這兩種模式時要注意的是,如果採用et模式,那麼僅當狀態發生變化時才會通知,而採用lt模式類似於原來的 select poll操作,只要還有沒有處理的事件就會一直通知.以 來說明問題 首先...