久久成人资源,欧美电影在线观看,国产日韩欧美亚洲一区

true — Wed, 22 Dec 2010 13:59:00 GMT

      wireshark�Q?a >http://www.wireshark.org/�Q�是我经常用到的抓包工具�Q�这对于�|�络�E�序的调试至关重要，特别是客��L��人员和服务端人员都认��q��代码没问题时�Q�wireshark本��n是开源的�Q�在windows�q�_��下基�?nbsp;winpcap�Q?a >http://www.winpcap.org/�Q�开发的�Q�安装wireshark的时候，会提�C�在�U�安装winpcap�Q�今天在�W�记本上用VS2008,�~�译了Examples-pcap下面的basic_dump和basic_dump_ex�Q�不曾想到的是抓不到包，甚是奇怪，因�ؓ用wireshark抓包是可以的�Q�因此怀疑是不是哪个参数设施不对�Q�终于比对wireshark�Q�得出结论：��pcap_open_live的第四个参数设�ؓ0�Q�即不能打开��h��模式�Q?br>
if ((adhandle= pcap_open_live(d->name, // name of the device
        65536,   // portion of the packet to capture.
           // 65536 grants that the whole packet will be captured on all the MACs.
        0,    // promiscuous mode (nonzero means promiscuous)
        1000,   // read timeout
        errbuf   // error buffer
        )) == NULL)
{
  fprintf(stderr,"\nUnable to open the adapter. %s is not supported by WinPcap\n", d->name);
  /* Free the device list */
  pcap_freealldevs(alldevs);
  return -1;
}

true 2010-12-22 21:59 发表评论

体验RakNet的RPC3

true — Mon, 05 Oct 2009 12:50:00 GMT

摘要: 初次接触了RakNet的RPC3�Q�RakNet是一个侧重于游戏的网�l�开发包阅读全文

true 2009-10-05 20:50 发表评论

协议设计之二 �l�构体类型的�~�码

true — Fri, 11 Sep 2009 11:35:00 GMT

摘要: �l�构体类型的序列�?nbsp; 阅读全文

true 2009-09-11 19:35 发表评论

true — Wed, 16 Jul 2008 05:19:00 GMT

#include
#include
#include

int main()
{
boost::asio::io_service io;

boost::asio::deadline_timer t(io, boost::posix_time::seconds(5));
t.wait();

std::cout << "Hello, world!\n";

return 0;
}

上面是boost文档自带的代码，�~�译出现错误。代码是不需要链接libboost_system-vc80-mt-gd-1_35.lib�Q��ؓ什么还出现�q�样的错误呢�Q�他默认�q�接�Q�知道的�Q�恢复一下：�Q?

true 2008-07-16 13:19 发表评论

true — Sun, 01 Jun 2008 14:55:00 GMT

epoll()实现分析

http://hi.baidu.com/rwen2012/blog/item/0f2f8c13eb7f3621dd5401a8.html

2007-07-04 17:50

/*
* This structure is stored inside the "private_data" member of the file
* structure and rapresent the main data sructure for the eventpoll
* interface.
*/
struct eventpoll {
   /* Protect the this structure access */
   rwlock_t lock;

true 2008-06-01 22:55 发表评论

在Linux上开发网�l�服务器的一些相关细�?poll与epoll[转]

true — Sun, 01 Jun 2008 14:15:00 GMT

http://hi.baidu.com/xproduct/blog/calendar/200706

2007-06-30 23:58

随着2.6内核对epoll的完全支持，�|�络上很多的文章和示例代码都提供了这样一个信息：使用epoll代替传统的poll能给�|�络服务应用带来性能�?的提升。但大多文章里关于性能提升的原因解释的较少�Q�这里我��试分析一下内核（2.6.21.1�Q�代码中poll与epoll的工作原理，然后再通过一�?��试数据来对比具体效果�?br>
   POLL�Q?br>
   先说poll�Q�poll或select为大部分Unix/Linux�E�序员所熟悉�Q�这俩个东西原理�c�M��Q�性能上也不存在明昑ַ�异，但select�Ҏ��监控的文件描�q�符数量有限�Ӟ��所以这里选用poll做说明�?br>
   poll是一个系�l�调用，其内核入口函��Cؓsys_poll�Q�sys_poll几乎不做��M��处理直接调用do_sys_poll�Q�do_sys_poll的执行过�E�可以分��Z��个部分：

   1�Q�将用户传入的pollfd数组拯��到内核空��_��因�ؓ拯��操作和数�l�长度相养I��旉��上这是一个O�Q�n�Q�操作，�q�一步的代码在do_sys_poll中包括从函数开始到调用do_poll前的部分�?br>
   2�Q�查询每个文件描�q�符对应讑֤�的状态，如果该设备尚未就�l�，则在该设备的�{�待队列中加入一��ƈ�l�箋查询下一讑֤�的状态。查询完所有设备后如果没有一个设备就�l�，�q�时则需要挂起当前进�E�等待，直到讑֤��q�A或者超�Ӟ��挂�v操作是通过调用schedule_timeout执行的。设备就�l�后�q�程被通知�l�箋�q?行，�q�时再次遍历所有设备，以查扑ְ��l�设备。这一步因��Z��ơ遍历所有设备，旉��复杂度也是O�Q�n�Q�，�q�里面不包括�{�待旉��。相关代码在do_poll函数中�?br>
   3�Q�将获得的数据传送到用户�I�间�q�执行释攑ֆ�存和剥离�{�待队列�{�善后工作，向用��L��间拷贝数据与剥离�{�待队列�{�操作的的时间复杂度同样是O�Q�n�Q�，具体代码包括do_sys_poll函数中调用do_poll后到�l�束的部分�?br>
   EPOLL�Q?br>
   接下来分析epoll�Q�与poll/select不同�Q�epoll不再是一个单独的�pȝ��调用�Q�而是由epoll_create/epoll_ctl/epoll_wait三个�pȝ��调用�l�成�Q�后面将会看到这样做的好处�?br>
   先来看sys_epoll_create(epoll_create对应的内核函敎ͼ��Q�这个函��C��要是做一些准备工作，比如创徏数据�l�构�Q�初始化数据�q�最�l�返回一个文件描�q�符�Q�表�C�新创徏的虚拟epoll文�g�Q�，�q�个操作可以认�ؓ是一个固定时间的操作�?br>
       epoll是做��Z��个虚拟文件系�l�来实现的，�q�样做至��有以下两个好处�Q?br>
       1�Q�可以在内核里维护一些信息，�q�些信息在多�ơepoll_wait间是保持的，比如所有受监控的文件描�q�符�?br>
       2�Q?epoll本��n也可以被poll/epoll;

   具体epoll的虚拟文件系�l�的实现和性能分析无关�Q�不再赘�q��?br>
   在sys_epoll_create中还能看��C��个细节，��是epoll_create的参数size在现阶段是没有意义的�Q�只要大于零��p��?br>
   接着是sys_epoll_ctl(epoll_ctl对应的内核函敎ͼ��Q�需要明��的是每�ơ调用sys_epoll_ctl只处理一个文件描�q�符�Q�这里主要描�q�当op为EPOLL_CTL_ADD时的执行�q�程�Q�sys_epoll_ctl做一些安全性检查后�q�入ep_insert�Q�ep_insert里将 ep_poll_callback做�ؓ回掉函数加入讑֤�的等待队列（假定�q�时讑֤��未��q�A�Q�，�׃��每次poll_ctl只操作一个文件描�q�符�Q�因此也可以认�ؓ�q�是一个O(1)操作

       ep_poll_callback函数很关键，它在所�{�待的设备就�l�后被系�l�回掉，执行两个操作�Q?br>
   1�Q�将��q�A讑֤�加入��q�A队列�Q�这一步避免了像poll那样在设备就�l�后再次轮询所有设备找��q�A者，降低了时间复杂度�Q�由O�Q�n�Q�到O�Q?�Q?

   2�Q�唤醒虚拟的epoll文�g;

   最后是sys_epoll_wait�Q�这里实际执行操作的是ep_poll函数。该函数�{�待��进�E�自�w�插入虚拟epoll文�g的等待队列，直到被唤醒（�?上面ep_poll_callback函数描述�Q�，最后执行ep_events_transfer��结果拷贝到用户�I�间。由于只拯��q�A讑֤�信息�Q�所以这里的拯��是一个O(1�Q�操作�?br>
   �q�有一个让人关心的问题��是epoll对EPOLLET的处理，卌��沿触发的处理�Q�粗略看代码��是把一部分水��^触发模式下内核做的工作交�l�用��h��处理�Q�直觉上不会�Ҏ��能有太大媄响，感兴��的朋友�Ƣ迎讨论�?br>
   POLL/EPOLL�Ҏ��Q?br>
   表面上poll的过�E�可以看作是�׃��ơepoll_create/若干�ơepoll_ctl/一�ơepoll_wait/一�ơclose�{�系�l�调用构成，实际上epoll��poll分成若干部分实现的原因正是因为服务器软�g中��用poll的特点（比如Web服务器）�Q?br>
   1�Q�需要同时poll大量文�g描述�W?

   2�Q�每�ơpoll完成后就�l�的文�g描述�W�只占所有被poll的描�q�符的很��一部分�?br>
   3�Q�前后多�ơpoll调用�Ҏ��件描�q�符数组�Q�ufds�Q�的修改只是很小;

   传统的poll函数相当于每�ơ调用都重�v炉灶�Q�从用户�I�间完整��d��ufds�Q�完成后再次完全拯��到用��L��_��另外每次poll都需要对所有设备做臛_��做一�ơ加入和删除�{�待队列操作�Q�这些都是低效的原因�?br>
       epoll��以上情况都�l�化考虑�Q�不需要每�ơ都完整��d��输出ufds�Q�只需使用epoll_ctl调整其中一��部分，不需要每��?epoll_wait都执行一�ơ加入删除等待队列操作，另外改进后的机制使的不必在某个设备就�l�后搜烦整个讑֤�数组�q�行查找�Q�这些都能提高效率。另外最�?昄��一点，从用��L��使用来说�Q��用epoll不必每次都轮询所有返回结果已扑և�其中的就�l�部分，O�Q�n�Q�变O�Q?�Q�，�Ҏ��能也提高不��?br>
   此外�q�里�q�发��C��点，是不是将epoll_ctl�Ҏ��一�ơ可以处理多个fd�Q�像semctl那样�Q�会提高些许性能呢？特别是在假设�pȝ��调用比较耗时的基��上。不�q�关于系�l�调用的耗时问题�q�会在以后分析�?br>
   POLL/EPOLL��试数据�Ҏ��Q?br>
   ��试的环境：我写了三�D�代码来分别模拟服务器，�z�d��的客��L��Q�僵�ȝ��客户端，服务器运行于一个自�~�译的标�?.6.11内核�pȝ��上，��g�?PIII933�Q�两个客��L��各自�q�行在另外的PC上，�q�两台PC比服务器的硬件性能要好�Q�主要是保证能轻易让服务器满载，三台机器间��用一�?00M交换 ��接�?br>
   服务器接受�ƈpoll所有连接，如果有request到达则回复一个response�Q�然后��l�poll�?br>
   �z�d��的客��L��Q�Active Client�Q�模拟若�q��ƈ发的�z�d��q�接�Q�这些连接不间断的发送请求接受回复�?br>
   僉|��的客��L��Q�zombie�Q�模拟一些只�q�接但不发送请求的客户端，其目的只是占用服务器的poll描述�W�资源�?br>
       ��试�q�程�Q�保�?0个�ƈ发活动连接，不断的调整僵�q�发�q�接敎ͼ�记录在不同比例下使用poll与epoll的性能差别。僵��dƈ发连接数�Ҏ��比例分别是：0�Q?0�Q?0�Q?0�Q?0�Q?60�Q?20�Q?40�Q?280�Q?560�Q?120�Q?0240�?br>
   下图中横轴表�C�僵��dƈ发连接与�z�d��q�发�q�接之比�Q�纵轴表�C�完�?0000�ơ请求回复所��p��的时��_��以秒为单位。红色线条表�C�poll数据�Q�绿色表�C?epoll数据。可以看出，poll在所监控的文件描�q�符数量增加�Ӟ��其耗时呈线性增长，而epoll则维持了一个��^�E�的状态，几乎不受描述�W�个数媄响�?br>
   在监控的所有客��L��都是�z�d��Ӟ��poll的效率会略高于epoll�Q�主要在原点附近�Q�即僉|��q�发�q�接�?�Ӟ��图上不易看出来）�Q�究竟epoll实现比poll复杂�Q�监控少量描�q�符�q��它的�?/div>

true 2008-06-01 22:15 发表评论

man epoll

true — Wed, 21 May 2008 06:43:00 GMT

EPOLL(4)                   Linux Programmer's Manual                  EPOLL(4)
NAME
epoll - I/O event notification facility
SYNOPSIS
#include 
DESCRIPTION
epoll  is a variant of poll(2) that can be used either as Edge or Level
Triggered interface and scales well to large numbers  of  watched  fds.
Three  system  calls  are  provided to set up and control an epoll set:
epoll_create(2), epoll_ctl(2), epoll_wait(2).
An epoll set is connected to a file descriptor  created  by  epoll_cre-
ate(2).   Interest  for certain file descriptors is then registered via
epoll_ctl(2).  Finally, the actual wait is started by epoll_wait(2).
NOTES
The epoll event distribution interface is able to behave both  as  Edge
Triggered  ( ET ) and Level Triggered ( LT ). The difference between ET
and LT event distribution mechanism can be described as  follows.  Sup-
pose that this scenario happens :
1      The file descriptor that represent the read side of a pipe ( RFD
) is added inside the epoll device.
2      Pipe writer writes 2Kb of data on the write side of the pipe.
3      A call to epoll_wait(2) is done that will return  RFD  as  ready
file descriptor.
4      The pipe reader reads 1Kb of data from RFD.
5      A call to epoll_wait(2) is done.
If  the RFD file descriptor has been added to the epoll interface using
the EPOLLET flag, the call to epoll_wait(2) done in step 5 will  proba-
bly  hang because of the available data still present in the file input
buffers and the remote peer might be expecting a response based on  the
data  it already sent. The reason for this is that Edge Triggered event
distribution delivers events only when events happens on the  monitored
file.  So, in step 5 the caller might end up waiting for some data that
is already present inside the input buffer. In the  above  example,  an
event on RFD will be generated because of the write done in 2 , and the
event is consumed in 3.  Since the read operation done in  4  does  not
consume the whole buffer data, the call to epoll_wait(2) done in step 5
might lock indefinitely. The epoll interface, when used with the  EPOL-
LET flag ( Edge Triggered ) should use non-blocking file descriptors to
avoid having a blocking read or write starve the task that is  handling
multiple  file  descriptors.  The suggested way to use epoll as an Edge
Triggered ( EPOLLET ) interface is  below,  and  possible  pitfalls  to
avoid follow.
i      with non-blocking file descriptors
ii     by  going  to  wait  for an event only after read(2) or write(2)
return EAGAIN
On the contrary, when used as a Level Triggered interface, epoll is  by
all means a faster poll(2), and can be used wherever the latter is used
since it shares the same semantics. Since even with the Edge  Triggered
epoll  multiple  events  can  be  generated  up on receival of multiple
chunks of data, the caller has the option to specify  the  EPOLLONESHOT
flag, to tell epoll to disable the associated file descriptor after the
receival of an event with epoll_wait(2).  When the EPOLLONESHOT flag is
specified,  it  is  caller  responsibility to rearm the file descriptor
using epoll_ctl(2) with EPOLL_CTL_MOD.
EXAMPLE FOR SUGGESTED USAGE
While the usage of epoll when employed like a Level Triggered interface
does  have  the  same  semantics  of  poll(2),  an Edge Triggered usage
requires more clarifiction to avoid stalls  in  the  application  event
loop.  In this example, listener is a non-blocking socket on which lis-
ten(2) has been called. The function do_use_fd()  uses  the  new  ready
file descriptor until EAGAIN is returned by either read(2) or write(2).
An event driven state machine application should, after having received
EAGAIN,  record  its  current  state  so  that  at  the  next  call  to
do_use_fd() it will continue to  read(2)  or  write(2)  from  where  it
stopped before.
struct epoll_event ev, *events;
for(;;) {
nfds = epoll_wait(kdpfd, events, maxevents, -1);
for(n = 0; n < nfds; ++n) {
if(events[n].data.fd == listener) {
client = accept(listener, (struct sockaddr *) &local,
&addrlen);
if(client < 0){
perror("accept");
continue;
}
setnonblocking(client);
ev.events = EPOLLIN | EPOLLET;
ev.data.fd = client;
if (epoll_ctl(kdpfd, EPOLL_CTL_ADD, client, &ev) < 0) {
fprintf(stderr, "epoll set insertion error: fd=%d0,
client);
return -1;
}
}
else
do_use_fd(events[n].data.fd);
}
}
When  used  as an Edge triggered interface, for performance reasons, it
is possible to add the file descriptor inside  the  epoll  interface  (
EPOLL_CTL_ADD  )  once  by specifying ( EPOLLIN|EPOLLOUT ). This allows
you to avoid continuously switching between EPOLLIN and EPOLLOUT  call-
ing epoll_ctl(2) with EPOLL_CTL_MOD.
QUESTIONS AND ANSWERS (from linux-kernel)
Q1     What happens if you add the same fd to an epoll_set twice?
A1     You  will  probably get EEXIST. However, it is possible that two
threads may add the same fd twice. This is a harmless condition.
Q2     Can  two  epoll  sets  wait  for  the same fd? If so, are events
reported to both epoll sets fds?
A2     Yes. However, it is not recommended. Yes it would be reported to
both.
Q3     Is the epoll fd itself poll/epoll/selectable?
A3     Yes.
Q4     What happens if the epoll fd is put into its own fd set?
A4     It  will  fail.  However, you can add an epoll fd inside another
epoll fd set.
Q5     Can I send the epoll fd over a unix-socket to another process?
A5     No.
Q6     Will the close of an fd cause it to be removed  from  all  epoll
sets automatically?
A6     Yes.
Q7     If more than one event comes in between epoll_wait(2) calls, are
they combined or reported separately?
A7     They will be combined.
Q8     Does an operation on an fd affect the already collected but  not
yet reported events?
A8     You  can  do  two  operations on an existing fd. Remove would be
meaningless for this case. Modify will re-read available I/O.
Q9     Do I need to continuously read/write an  fd  until  EAGAIN  when
using the EPOLLET flag ( Edge Triggered behaviour ) ?
A9     No  you don't. Receiving an event from epoll_wait(2) should sug-
gest to you that such file descriptor is ready for the requested
I/O  operation.  You  have simply to consider it ready until you
will receive the next EAGAIN. When and how  you  will  use  such
file  descriptor is entirely up to you. Also, the condition that
the read/write I/O space is exhausted can be detected by  check-
ing  the  amount  of  data  read/write  from/to  the target file
descriptor. For example, if you call read(2) by asking to read a
certain  amount  of  data  and read(2) returns a lower number of
bytes, you can be sure to have exhausted the read I/O space  for
such  file  descriptor.  Same  is  valid  when writing using the
write(2) function.
POSSIBLE PITFALLS AND WAYS TO AVOID THEM
o Starvation ( Edge Triggered )
If there is a large amount of I/O space, it is possible that by  trying
to  drain it the other files will not get processed causing starvation.
This is not specific to epoll.
The solution is to maintain a ready list and mark the  file  descriptor
as  ready in its associated data structure, thereby allowing the appli-
cation to remember which files need to be  processed  but  still  round
robin  amongst  all the ready files. This also supports ignoring subse-
quent events you receive for fd's that are already ready.
o If using an event cache...
If you use  an  event  cache  or  store  all  the  fd's  returned  from
epoll_wait(2),  then  make  sure  to  provide a way to mark its closure
dynamically (ie- caused by a previous event's processing). Suppose  you
receive  100  events  from epoll_wait(2), and in eventi #47 a condition
causes event #13 to be closed.  If you remove the structure and close()
the  fd  for event #13, then your event cache might still say there are
events waiting for that fd causing confusion.
One solution for this is to call, during the processing  of  event  47,
epoll_ctl(EPOLL_CTL_DEL)  to  delete  fd  13 and close(), then mark its
associated data structure as removed and link it to a cleanup list.  If
you  find  another  event  for fd 13 in your batch processing, you will
discover the fd had been previously removed and there will be no confu-
sion.
CONFORMING TO
epoll(4) is a new API introduced in Linux kernel 2.5.44.  Its interface
should be finalized in Linux kernel 2.5.66.
SEE ALSO
epoll_create(2) epoll_ctl(2) epoll_wait(2)
Linux                           23 October 2002                       EPOLL(4)

true 2008-05-21 14:43 发表评论