感谢你对这个框架的关注。我一一回答你的问题。
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正在紧张的开发中，很多朋友提出了很好的改进意见，我会一一吸收在其中。
搞了半天终于注册好了！！
刚刚看了一下，的确是好东东，
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);执行到这里崩溃
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()里
好东西，顶一个
顶一个，呵呵呵。。。。
很久没有在这里发言了，呵呵。
因为最近工作较忙，而且在做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个左右。当然，这部分客户端还在优化中，如果客户端做成异步，估计效能应该还会更高。
如果有兴趣，请大家耐心等待，应该不会太长的时间，这个版本会更加高效而稳定的出来。
0.84版本发布了，有兴趣请大家多提提意见。
这个必须强烈支持！