freeeyes
发表于 2012-1-17 09:13:08
感谢你对这个框架的关注。我一一回答你的问题。
1.ACE_Strategy_Acceptor这个类我没有使用过,这部分这段时间我好好看看,如果可以的话,我整合到新版的系统中去。
2.ConnectHandler.cpp中的send和recv中的时间参数,我认为是指的当前发送或者接受的超时时间,如果设置为0,则是直到发送完成之前一直阻塞,我曾经遇到过因为某些网络原因,当timeout设置为0的时候,当前线程一直阻塞等待发送结束的情况。这会造成其他的发送数据无法进行。所以在这里,我追加了这个超时的时间,对于我目前的系统而言,我使用的是非阻塞的epol,所以这里的send并不是真正的发送出去。设置超时时间是为了防止其他的发送数据行为过长等待。
3.我在0.44版本中的时候大量使用了handle_output,但是发现这个模式使用有一些让人容易进入开发误区的地方。当ACE_WFMO_Reactor回调到handle_output时你可以认为一直可写,直到写操作返回EWOULDBLOCK为止。如果socket一直都可以写,ACE_WFMO_Reactor只会调用一次handle_output。因为socket本身的状态没有发生改变,ACE_WFMO_Reactor不会将它放在待分派的事件源中。那么下一次调用handle_output会是什么时候呢?答案是socket从不可写状态变为可写。这就是所谓的“边缘触发方式”。
再来看看ACE_Select_Reactor。Select_Reactor基于BSD Socket的select系统函数,使用的是“水平触发方式”。也就是说,如果socket可写,ACE_Select_Reactor就会不停地调用handle_output,可以说它是比较勤快和公平的。
那么,如果开发者使用不同的模式,就会导致框架代码必须根据不同的模式进行匹配,增加了代码开发的复杂度和阅读的难度。
综合以上考虑,我后来一律使用自己写的简单的send队列去做。
4.ACE的单件其实是受ACE生存周期控制的,起始于ACE::init();终止于ACE::fini();目前我的框架并不区分从哪个端口来的数据,对于我来说,框架端口只是入口罢了,数据处理的方法,全部交由逻辑模块处理,多端口,只是对应多入口。至于实际数据的处理和区分,我认为放在逻辑模块中去做比较好。
以上是我个人的一些想法,如果你有兴趣,可以和我讨论。我非常喜欢好的想法,如果确实合理,我会优化在目前的框架中。
目前0.84正在紧张的开发中,很多朋友提出了很好的改进意见,我会一一吸收在其中。
staceplayer
发表于 2012-1-18 17:44:50
搞了半天终于注册好了!!
ztenv
发表于 2012-1-29 14:46:07
刚刚看了一下,的确是好东东,
hu__yong
发表于 2012-2-1 08:59:05
freeeyes 发表于 2012-1-17 09:13 static/image/common/back.gif
感谢你对这个框架的关注。我一一回答你的问题。
1.ACE_Strategy_Acceptor这个类我没有使用过,这部分这段时 ...
bool CClientReConnectManager::SendData(int nServerID, const char* pData, int nSize)
{
ACE_Guard<ACE_Recursive_Thread_Mutex> guard(m_ThreadWritrLock);
mapReactorConnectInfo::iterator f = m_mapConnectInfo.find(nServerID);
if(f == m_mapConnectInfo.end())
{
//如果这个链接已经存在,则不创建新的链接
OUR_DEBUG((LM_ERROR, "nServerID =(%d) is not exist.\n", nServerID));
SAFE_DELETE_ARRAY(pData);
return false;
}
CReactorClientInfo* pClientInfo = (CReactorClientInfo* )f->second;
ACE_Message_Block* pmblk = App_MessageBlockManager::instance()->Create(nSize);
if(NULL == pmblk)
{
OUR_DEBUG((LM_ERROR, "nServerID =(%d) pmblk is NULL.\n", nServerID));
SAFE_DELETE_ARRAY(pData);
return false;
}
ACE_OS::memcpy(pmblk->wr_ptr(), pData, nSize);
pmblk->wr_ptr(nSize);
//-- SAFE_DELETE_ARRAY(pData);
//发送数据
return pClientInfo->SendData(pmblk);
}
SAFE_DELETE_ARRAY(pData);执行到这里崩溃
hu__yong
发表于 2012-2-1 09:03:42
freeeyes 发表于 2012-1-17 09:13 static/image/common/back.gif
感谢你对这个框架的关注。我一一回答你的问题。
1.ACE_Strategy_Acceptor这个类我没有使用过,这部分这段时 ...
//启动中间服务器链接管理器
/*App_ClientReConnectManager::instance()->Init(App_ReactorManager::instance()->GetAce_Reactor(REACTOR_POSTDEFINE));
App_ClientReConnectManager::instance()->StartConnectTask(CONNECT_LIMIT_RETRY);*/
两个模式下的中间服务器连接是否应该放在Init()里 而不是Start()里
wshbjt
发表于 2012-2-1 11:14:35
好东西,顶一个
jacktian
发表于 2012-2-19 22:42:00
顶一个,呵呵呵。。。。
freeeyes
发表于 2012-2-27 10:54:56
很久没有在这里发言了,呵呵。
因为最近工作较忙,而且在做0.84版本的较大更新。这次更新时间比较长的原因是,我开始对这个架构在linux下的性能开始优化。以前没有系统的去整理这一块,近两个月,我把主要精力集中在这里。并对有些基础架构进行了重写和添加。
这里要强烈感谢 ZZZ 的大力帮助。并帮助我写出了新的压测客户端,并在实际测试中,发现了一些问题。这段时间,解决这些问题,并提供新的一些功能。是我的主要目的,我希望0.84推出的时候,能给大家一个惊喜。那么,也不废话了,说说这两个月我主要做了一些什么。
1.开始在Linux下使用valgrand帮助我的代码判断,添加了两个脚本,一个是valgrind-efc.run(用于监控,在程序运行时,所有函数第调用时间,包括多线程下的不同函数,用于找出哪个函数执行时间多造成的性能损耗),一个是valgrind-mem.run(用于监控程序运行的内存泄露,并给出泄露的代码位置)。这两个脚本都必须在安装valgrind以后才能使用。至于这部分的使用,我会给出一个文档予以说明。
2.添加了消息到达处理时间,和消息发送时间的性能指标(单位是纳秒级,用于监控框架在消息处理的下的时间)
3.重写了发送方法,上层接口调用不变,支持多线程的数据发送。不同的链接可以在不同的线程下发送,达到并行的目的,但是前提是,你需要估算你的CPU核心是否可以满足你的线程数,过多的发送线程可能会造成实际效率下降。这一部分,你可以通过配置文件进行管理。
4.优化了消息信息,你可以管理监控一个完整的消息被处理的时间和次数。
5.追加了日志,添加了接收超时和发送超时的日志信息。定时输出了BUffPacket内存池的管理情况。
6.修改了一些BUG,并合并优化了一些无用的代码。
7.客户端添加了压测客户端。
8.对原有的PsClient链接压测部分进行了重写。
以上的改动由于比较多,花的时间比较长,不过相信出来以后,大家能够看到它的进步。
目前在我的虚拟机下,ContOS6,客户端在别的机器上,10个线程并发压测,处理消息包基本在15000个左右。当然,这部分客户端还在优化中,如果客户端做成异步,估计效能应该还会更高。
如果有兴趣,请大家耐心等待,应该不会太长的时间,这个版本会更加高效而稳定的出来。
freeeyes
发表于 2012-3-12 14:03:36
0.84版本发布了,有兴趣请大家多提提意见。
Dragon006
发表于 2012-3-12 17:34:12
这个必须强烈支持!