2014-08-26 20:06:24
今天就是在开发这个EPOLL来处理网络事件 封装较为健壮的EPOLL模型来处理基本的网络IO
1) 超时这个主题先没有弄
在开发EPOLL包括select/poll类型io复用时，编程技术技巧分为几点：【下面都是针对与TCP协议 如果在以后开发中需要UDP会扩展这个编程技术】
1 要处理的文件描述符种类
a) listenfd=socket(); 这个listenfd 就是监听的listenfd 我们暂且把他作为一个总IO文件 其实这个listenfd就是一个数组索引。利用EPOLL监听的这个listenfd READBLE状态，那么这里肯定需要放一个TCPAcceptHandler的函数来做相应的操作 因为监听到相应的核心东东就是一系列raw的客户端传来的信息：
其中有 ip fd port 作为一个功能完善的程序 ip fd port 这些作为raw信息 外加一系列RBL服务端所要控制的信息 构造了RBLClient的这个重量级数据结构，这样网络层和RBL服务层能够通过这个数据结构进行结合了。TCPAcceptHandler在目前看来就是做这个事情。
b) 在a阶段构造了RBLClient 但是这个只是做了TCP的raw的ACCPET操作，但是需要引入真正的逻辑操作，也就是RBLServer接受到的所有的无论是自身的还是客户端的数据通信。 这里要利用typedef void FileProc(EpollEventLoop* ep,void *data,int fd) 给每一个来处理的文件的描述符注册一个通用的函数指针。这点内存消耗是必须的。这点暂时也不考虑了 这个阶段就是完成了注册事件。其实在这里需要处理可读和可写个事件 1) 可读是通过这层 交付给其他服务部分，2) 可写其他组建【自身】交给网络终端。
2 做成一个可以可随时插入的事件处理模型
在实现上要像REDIS一样，随时可以插入事件 比如建立一个EPOLLLOOP对象之后，在后面的N个步骤之后 咱们插入一个listenfd到EPOLLLOOP对象里。
在或者 我处理完一个客户端命令我需要告诉他该怎么做 也是通过回调事件来完成。 同时由于客户端随时挂掉或者主动离开 需要做DEL功能。 这些看起来是显而易见 但是需要仔细封装好。【在REDIS中是注入了readQueryFromClient/ sendReplyToClient这2个事件函数】所以呢 嘿嘿 面对这么优秀的REDIS设计 我还是利用的模式 不过在哪里潜入这2个函数呢？ 需要仔细的体会体会哦
另外定义一个什么样的协议呢？ 兼容REDIS 我采用同样的协议模式。
简单的类定义如下：
class EpollEventLoop
{
public:
EpollEventLoop(int maxclient_):maxclient(maxclient_),maxepollevent(maxclient_),maxfd(-1)
{
epollfd=epoll_create(2048);
if(epollfd==-1)
std::cout<<"epoll create failed!"<<std::endl;
}
void CreatFileEvent(int fd,FileEvent* prere_event); //这里其实是注册事件
void DeleteFileEvent(int fd,int mask); //这里是删除事件
void ProcessEvents(int flag);//flag代表是那种类型的事件 在这里就是读写事件
~EpollEventLoop()
{
}
private:
int maxfd; //当前注册最大文件数目 eventloop初始化为-1
std::vector<FileEvent> fileevent; //文件事件 用std::vector存储
int epollfd; //epollfd文件描述符
std::vector<struct epoll_event> maxepollevent;
int maxclient;
};
REDIS协议实现起来比较繁琐的是批处理操作：
*<参数数量> CR LF $<参数 1 的字节数量> CR LF <参数 1 的数据> CR LF ... $<参数 N 的字节数量> CR LF <参数 N 的数据> CR LF这样看来：传入上面总结的3个function(readQueryFromClient/ sendReplyToClient/TCPAcceptHandler)上都是以RBLClient做为主参数，解码或者加码都是在readQueryFromClient/ sendReplyToClient函数完成。实现上还有一个难点：就是加码或者解码时这边传入的数据缓冲区不够怎么办？不能一下子放到结构化数据中，那就在实现时 做一个标记位，分多次读完 这样确实麻烦 这样在RBLClient就要多加几个结构来控制这些量了。 快哭了 网络协议部分http://www.redisdoc.com/en/latest/topic/protocol.html 就参考这个了 简化它 毕竟没有REDIS命令那么多 接下来是一个头痛的问题：上面的实现版本是单线程模式： 接下来该怎么实现一个多线程呢？ EPOLL线程：加入任务队列WorkQueue中， 是把什么加入到这个WorkQueue中呢？ 其实就是把一个个RBLClient副本到WorkQueue中，而消费线程也就是调用TakeQueue() 形式化：
LOCK1() TakeQUEUE() UNLOCK1() …… …… LOCK2() CommandExecute() UNLOCK2()
对于LOCK1部分的实现 用无锁队列
对于LOCK2 这里实现有一个CommandExecute() 这里就是控制一个部分bit数组 所以对我来讲 这个地方如果采用spin_lock() 加锁会不会好一一些呢？ 这个需要评估
另外而言： 对于一致性而言，这样的操作模式 对于单客户可能不会马上得到想要的结果 这是一种必须的 是需要一个时间窗口 并非强一致性 我这里是牺牲了强一致性的 但是如果WorkQueue一直非常小的话 这个时间窗口肯定就非常小了 对应用程序造不成很大的影响。
明天的实现部分估计就是这个最难熬的线程控制部分了 这个部分计划用2到3天完成。明天把EventLoop代码实现的部分和协议实现部分先贴出来 然后串讲下思路先这样了 bye