现在的位置: 首页 > 综合 > 正文

快速构建MMO服务器框架(三)boost.asio初步

2013年08月26日 ⁄ 综合 ⁄ 共 3362字 ⁄ 字号 评论关闭

 c10k问题已经成为历史。(详细)

 Boost.Asio is a cross-platform C++ library for network and low-level I/O
programming that provides developers with a consistent asynchronous model using
a modern C++ approach. (详细)

通过asio,可以以很简洁的方式处理网络连接,如以下例子,创建了一个异步的TCP服务器(转自boost.asio的tutorial):

(注:上例要编译通过需要链接boost的system库,在linux环境下的文件名为libboost_system-mt.so。linux下普通用户权限运行,出现permission denied错误,把 acceptor_(io_service, tcp::endpoint(tcp::v4(), 13))的端口号13改为0-1023(IANA保留)之外的端口号即可)

以上代码做的事情:
创建一个tcp服务器,监听并异步accept;
accept成功后建立连接,异步发送当前时间字符串,继续accept...

寥寥几行代码,一个在当前主流服务器硬件配置下可以支持数万连接的tcp服务器就已经架设起来了。再配合boost的timer,简单的单服网游框架嫩芽已经破土而出了,哇哈哈。

此处,还有一些需要稍微深入的细节:
1、io_service所实现的是proactor模式。关于proactor和reactor模式的区别,不想装B的话可以简单理解成 proactor在读写操作完成后才通知(即异步io,典型的实现如iocp),reactor是在可进行读写时通知用户去操作(如epoll),(深入)
。实际上,io_service在windows下的实现就用了iocp,linux下的内部实现是epoll reactor(也可以换成poll / select)。由此引出第二个问题:
2、linux下asio的epoll用了et还是lt模式?粗略看了一下源代码,没发现et的影子。boost的mail list中作者也表示有把实现改成采用et模式的计划,不过日期是2005年的,目前最新的版本(boost 1.41)都还没实现,这效率...硬件性能都已经符合摩尔定律翻了几番了,当然在我朝同样符合摩尔定律的还有房价。
3、如果关联到io_service的socket是阻塞的,结果会怎样?以上代码并没有调用设置non blocking的选项。似乎“同步”“异步”“阻塞”“非阻塞”的定义在这里区分得也比较明晰,比如 reactor+非阻塞socket 就称为non-blocking synchronous。推测可能会出现的现象是blocking的socket影响了当前所在线程的其它socket的并发。
4、timer的列表是如何维护的?粗略看了一下实现,timer按照触发时间保存在二叉堆中,每次步进则执行触发时间<当前时间的timer。而timer本身也记录了在heap中的索引,可以实现快速删除,比较高效。
5、如果采用epoll实现的io_service运行在单线程下,那么有可能会出现处理网络io的时间太长,影响了游戏逻辑处理的情况。多线程的io_service有什么猫腻还要继续研究。

今天先写到这吧。

抱歉!评论已关闭.