12月 2009

偶尔发现，我竟然还保存着当年毕业的那几天的记录，把这些流水的句子看看，发现竟然还能回忆起那年的许多。

走到记忆里，仿佛是另一个世界，或许当年的我们都会在心中想起不同的情景，有一点却是相同的，那些日子里我们一起走过。人生有许多的过去和未来，那最好的年华在哪里，又是怎样度过的呢？每个人的心里总会有不同的答案。
—————————————————————————————————————————————
7月7日 read more

  原文地址 http://hi.baidu.com/firefly0510/blog/item/1ae20a4ac2fe01f883025cfc.html
epoll的实现原理
2009-04-17 13:05

1 功能介绍
     epoll与select/poll不同的一点是，它是由一组系统调用组成。
     int epoll_create(int size);
     int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);
     int epoll_wait(int epfd, struct epoll_event *events,int maxevents, int timeout);
     epoll相关系统调用是在Linux 2.5.44开始引入的。该系统调用针对传统的select/poll系统调用的不足，设计上作了很大的改动。select/poll的缺点在于：
     1.每次调用时要重复地从用户态读入参数。
     2.每次调用时要重复地扫描文件描述符。
     3.每次在调用开始时，要把当前进程放入各个文件描述符的等待队列。在调用结束后，又把进程从各个等待队列中删除。
     在实际应用中，select/poll监视的文件描述符可能会非常多，如果每次只是返回一小部分，那么，这种情况下select/poll显得不够高效。epoll的设计思路，是把select/poll单个的操作拆分为1个epoll_create+多个epoll_ctrl+一个wait。此外，
内核针对epoll操作添加了一个文件系统”eventpollfs”，每一个或者多个要监视的文件描述符都有一个对应的eventpollfs文件系统的inode节点，主要信息保存在eventpoll结构体中。而被监视的文件的重要信息则保存在epitem结构体中。所以他们
是一对多的关系。
     由于在执行epoll_create和epoll_ctrl时，已经把用户态的信息保存到内核态了，所以之后即使反复地调用epoll_wait，也不会重复地拷贝参数，扫描文件描述符，反复地把当前进程放入/放出等待队列。这样就避免了以上的三个缺点。
     接下去看看它们的实现：
2 关键结构体：
/* Wrapper struct used by poll queueing */
struct ep_pqueue {
         poll_table pt;
         struct epitem *epi;
};
     这个结构体类似于select/poll中的struct poll_wqueues。由于epoll需要在内核态保存大量信息，所以光光一个回调函数指针已经不能满足要求，所以在这里引入了一个新的结构体struct epitem。
/*
 * Each file descriptor added to the eventpoll interface will
 * have an entry of this type linked to the hash.
 */
struct epitem {
         /* RB-Tree node used to link this structure to the eventpoll rb-tree */
         struct rb_node rbn;红黑树，用来保存eventpoll
         /* List header used to link this structure to the eventpoll ready list */
         struct list_head rdllink;双向链表，用来保存已经完成的eventpoll
         /* The file descriptor information this item refers to */
         struct epoll_filefd ffd;这个结构体对应的被监听的文件描述符信息
         /* Number of active wait queue attached to poll operations */
         int nwait;poll操作中事件的个数
         /* List containing poll wait queues */
         struct list_head pwqlist;双向链表，保存着被监视文件的等待队列，功能类似于select/poll中的poll_table
         /* The "container" of this item */
         struct eventpoll *ep;指向eventpoll，多个epitem对应一个eventpoll
         /* The structure that describe the interested events and the source fd */
         struct epoll_event event;记录发生的事件和对应的fd
         /*
          * Used to keep track of the usage count of the structure. This avoids
          * that the structure will desappear from underneath our processing.
          */
         atomic_t usecnt;引用计数
         /* List header used to link this item to the "struct file" items list */
         struct list_head fllink;双向链表，用来链接被监视的文件描述符对应的struct file。因为file里有f_ep_link，用来保存所有监视这个文件的epoll节点
         /* List header used to link the item to the transfer list */
         struct list_head txlink;双向链表，用来保存传输队列
         /*
          * This is used during the collection/transfer of events to userspace
          * to pin items empty events set.
          */
         unsigned int revents;文件描述符的状态，在收集和传输时用来锁住空的事件集合
};
     该结构体用来保存与epoll节点关联的多个文件描述符，保存的方式是使用红黑树实现的hash表。至于为什么要保存，下文有详细解释。它与被监听的文件描述符一一对应。
struct eventpoll {
         /* Protect the this structure access */
         rwlock_t lock;读写锁
         /*
          * This semaphore is used to ensure that files are not removed
          * while epoll is using them. This is read-held during the event
          * collection loop and it is write-held during the file cleanup
          * path, the epoll file exit code and the ctl operations.
          */
         struct rw_semaphore sem;读写信号量
         /* Wait queue used by sys_epoll_wait() */
         wait_queue_head_t wq;
         /* Wait queue used by file->poll() */
         wait_queue_head_t poll_wait;
         /* List of ready file descriptors */
         struct list_head rdllist;已经完成的操作事件的队列。
         /* RB-Tree root used to store monitored fd structs */
         struct rb_root rbr;保存epoll监视的文件描述符
};
     这个结构体保存了epoll文件描述符的扩展信息，它被保存在file结构体的private_data中。它与epoll文件节点一一对应。通常一个epoll文件节点对应多个被监视的文件描述符。所以一个eventpoll结构体会对应多个epitem结构体。     那么，epoll中的等待事件放在哪里呢？见下面 read more

 原文地址 http://blog.chinaunix.net/u2/76292/showart_2062690.html
昨天在CU上看到epoll, 自己既然还从来没听说过. google了一下.
练习了一下, 太懒, 本来可以写的更好写. 以下是从
/**
 * http://blog.csdn.net/mote_li/archive/2004/12/08/209450.aspx
 */
修改的. 关键是学习他的epoll使用, 其它的就别了. 自己编译测试了一下, 感觉有点意思就share一下.
  read more

 原文地址 http://zhoulifa.bokee.com/6068027.html
什么是异步通讯？
就是通讯任意一方可以任意发送消息，有消息来到时会收到系统提示去接收消息。

这里要用到select函数。使用步骤如下：
1、设置一个集合变量，用来存放所有要判断的句柄（file descriptors：即我们建立的每个socket、用open打开的每个文件等）
2、把需要判断的句柄加入到集合里
3、设置判断时间
4、开始等待，即select
5、如果在设定的时间内有任何句柄状态变化了就马上返回，并把句柄设置到集合里 read more

 原文地址 http://www.uumbbs.com/show_topic.aspx?topicId=3084&forumId=208
Select在Socket编程中还是比较重要的，可是对于初学Socket的人来说都不太爱用Select写程序，他们只是习惯写诸如connect、 accept、recv或recvfrom这样的阻塞程序（所谓阻塞方式block，顾名思义，就是进程或是线程执行到这些函数时必须等待某个事件的发生，如果事件没有发生，进程或线程就被阻塞，函数不能立即返回）。可是使用Select就可以完成非阻塞（所谓非阻塞方式non-block，就是进程或线程执行此函数时不必非要等待事件的发生，一旦执行肯定返回，以返回值的不同来反映函数的执行情况，如果事件发生则与阻塞方式相同，若事件没有发生则返回一个代码来告知事件未发生，而进程或线程继续执行，所以效率较高）方式工作的程序，它能够监视我们需要监视的文件描述符的变化情况——读写或是异常。下面详细介绍一下！ read more

作者：CppExplore 网址：http://www.cppblog.com/CppExplore/
本章主要列举服务器程序的各种网络模型，示例程序以及性能对比后面再写。
一、分类依据。服务器的网络模型分类主要依据以下几点
（1）是否阻塞方式处理请求，是否多路复用，使用哪种多路复用函数
（2）是否多线程，多线程间如何组织
（3）是否多进程，多进程的切入点一般都是accept函数前
二、分类。首先根据是否多路复用分为三大类：
（1）阻塞式模型
（2）多路复用模型
（3）实时信号模型
三、详细分类。
1、阻塞式模型根据是否多线程分四类：
（1）单线程处理。实现可以参见http://www.cppblog.com/CppExplore/archive/2008/03/14/44509.html后面的示例代码。
（2）一个请求一个线程。
主线程阻塞在accept处，新连接到来，实时生成线程处理新连接。受限于进程的线程数，以及实时创建线程的开销，过多线程后上下文切换的开销，该模型也就是有学习上价值。
（3）预派生一定数量线程，并且所有线程阻塞在accept处。
该模型与下面的（4）类似与线程的领导者/追随者模型。
传统的看法认为多进程（linux上线程仍然是进程方式）同时阻塞在accept处，当新连接到来时会有“惊群”现象发生，即所有都被激活，之后有一个获取连接描述符返回，其它再次转为睡眠。linux从2.2.9版本开始就不再存在这个问题，只会有一个被激活，其它平台依旧可能有这个问题，甚至是不支持所有进程直接在accept阻塞。
（4）预派生一定数量线程，并且所有线程阻塞在accept前的线程锁处。
一次只有一个线程能阻塞在accept处。避免不支持所有线程直接阻塞在accept，并且避免惊群问题。特别是当前linux2.6的线程库下，模型（3）没有存在的价值了。另有文件锁方式，不具有通用性，并且效率也不高，不再单独列举。
（5）主线程处理accept，预派生多个线程（线程池）处理连接。
类似与线程的半同步/半异步模型。
主线程的accept返回后，将clientfd放入预派生线程的线程消息队列，线程池读取线程消息队列处理clientfd。主线程只处理accept，可以快速返回继续调用accept，可以避免连接爆发情况的拒绝连接问题，另加大线程消息队列的长度，可以有效减少线程消息队列处的系统调用次数。
（6）预派生多线程阻塞在accept处，每个线程又有预派生线程专门处理连接。
（3）和（4）/（5）的复合体。
经测试，（5）中的accept线程处理能力非常强，远远大于业务线程，并发10000的连接数也毫无影响，因此该模型没有实际意义。
总结：就前五模型而言，性能最好的是模型（5）。模型（3）/(4)可以一定程度上改善模型（1）的处理性能，处理爆发繁忙的连接，仍然不理想。。阻塞式模型因为读的阻塞性，容易受到攻击，一个死连接（建立连接但是不发送数据的连接）就可以导致业务线程死掉。因此内部服务器的交互可以采用这类模型，对外的服务不适合。优先（5），然后是（4），然后是（1），其它不考虑。
2、多路复用模型根据多路复用点、是否多线程分类：
以下各个模型依据选用select/poll/epoll又都细分为3类。下面个别术语采用select中的，仅为说明。
（1）accept函数在多路复用函数之前，主线程在accept处阻塞，多个从线程在多路复用函数处阻塞。主线程和从线程通过管道通讯，主线程通过管道依次将连接的clientfd写入对应从线程管道，从线程把管道的读端pipefd作为fd_set的第一个描述符，如pipefd可读，则读数据，根据预定义格式分解出clientfd放入fd_set，如果clientfd可读，则read之后处理业务。
此方法可以避免select的fd_set上限限制，具体机器上select可以支持多少个描述符，可以通过打印sizeof(fd_set)查看，我机器上是512字节，则支持512×8＝4096个。为了支持多余4096的连接数，此模型下就可以创建多个从线程分别多路复用，主线程accept后平均放入（顺序循环）各个线程的管道中。创建5个从线程以其对应管道，就可以支持2w的连接，足够了。另一方面相对与单线程的select，单一连接可读的时候，还可以减少循环扫描fd_set的次数。单线程下要扫描所有fd_set（如果再最后），该模型下，只需要扫描所在线程的fd_set就可。
（2）accept函数在多路复用函数之前，与（1）的差别在于，主线程不直接与从线程通过管道通讯，而是将获取的fd放入另一缓存线程的线程消息队列，缓存线程读消息队列，然后通过管道与从线程通讯。
目的在主线程中减少系统调用，加快accept的处理，避免连接爆发情况下的拒绝连接。
（3）多路复用函数在accept之前。多路复用函数返回，如果可读的是serverfd，则accept，其它则read，后处理业务，这是多路复用通用的模型，也是经典的reactor模型。
（4）连接在单独线程中处理。
以上（1）（2）（3）都可以在检测到cliendfd可读的时候，把描述符写入另一线程（也可以是线程池）的线程消息队列，另一线程（或线程池）负责read，后处理业务。
（5）业务线程独立，下面的网络层读取结束后通知业务线程。
以上（1）（2）（3）（4）中都可以将业务线程（可以是线程池）独立，事先告之（1）、（2）、（3）、（4）中read所在线程（上面1、2、4都可以是线程池），需要读取的字符串结束标志或者需要读取的字符串个数，读取结束，则将clientfd/buffer指针放入业务线程的线程消息队列，业务线程读取消息队列处理业务。这也就是经典的proactor模拟。
总结：模型（1）是拓展select处理能力不错选择；模型（2）是模型（1）在爆发连接下的调整版本；模型（3）是经典的reactor，epoll在该模型下性能就已经很好，而select/poll仍然存在爆发连接的拒绝连接情况；模型（4）（5）则是方便业务处理，对模型（3）进行多线程调整的版本。带有复杂业务处理的情况下推荐模型（5）。根据测试显示，使用epoll的时候，模型（1）（2）相对（3）没有明显的性能优势，（1）由于主线程两次的系统调用，反而性能下降。
3、实时信号模型：
使用fcntl的F_SETSIG操作，把描述符可读的信号由不可靠的SIGIO(SYSTEM V)或者SIGPOLL(BSD)换成可靠信号。即可成为替代多路复用的方式。优于select/poll，特别是在大量死连接存在的情况下，但不及epoll。
四、多进程的参与的方式
（1）fork模型。fork后所有进程直接在accept阻塞。以上主线程在accept阻塞的都可以在accept前fork为多进程。同样面临惊群问题。
（2）fork模型。fork后所有进程阻塞在accept前的线程锁处。同线程中一样避免不支持所有进程直接阻塞在accept或者惊群问题，所有进程阻塞在共享内存上实现的线程互斥锁。
（3）业务和网络层分离为不同进程模型。这个模型可能是受unix简单哲学的影响，一个进程完成一件事情，复杂的事情通过多个进程结合管道完成。我见过进程方式的商业协议栈实现。自己暂时还没有写该模型的示例程序测试对比性能。
（4）均衡负载模型。起多个进程绑定到不同的服务端口，前端部署lvs等均衡负载系统，暴露一个网络地址，后端映射到不同的进程，实现可扩展的多进程方案。
总结：个人认为（1）（2）没什么意义。（3）暂不评价。（4）则是均衡负载方案，和以上所有方案不冲突。
以上模型的代码示例以及性能对比后面给出。 read more

 原文地址 http://www.cnblogs.com/shelvenn/articles/969227.html
第二部分

第一章
客户机设置
UDP 客户机的前几行与 TCP 客户机的对应行完全相同。我们主要是使用了几个 include 语句来包含 socket 函数，或其他基本的 I/O 函数。

          #include <stdio.h>
          #include <sys/socket.h>
          #include <arpa/inet.h>
          #include <stdlib.h>
          #include <string.h>
          #include <unistd.h>
          #include <netinet/in.h> read more

多路复用的方式是真正实用的服务器程序，非多路复用的网络程序只能作为学习或着陪测的角色。本文说下个人接触过的多路复用函数：select/poll /epoll/port。kqueue的*nix系统没接触过，估计熟悉了上面四种，kqueue也只是需要熟悉一下而已。
一、select模型
select原型：
int select(int n, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout); read more

http://blog.chinaunix.net/u2/67780/showart_2057153.html
WINDOWS完成端口编程
1、基本概念
2、WINDOWS完成端口的特点
3、完成端口（Completion Ports ）相关数据结构和创建
4、完成端口线程的工作原理
5、Windows完成端口的实例代码
Linux的EPoll模型
1、为什么select落后
2、内核中提高I/O性能的新方法epoll
3、epoll的优点
4、epoll的工作模式
5、epoll的使用方法
6、Linux下EPOll编程实例
总结 read more