epoll 學習筆記

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;

//ev.events

=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

) #!/

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學習筆記

epoll學習筆記

Epoll學習筆記

epoll 學習筆記

epoll學習筆記

epoll學習筆記

Epoll學習筆記

相關推薦