基于boost::asio的网络socket服务端
一直以来,我们总是纠结网络服务器开发模型、线程、效率、优化等等
相对比较好一点的理论上大的概念都知道Win下使用IOCP、Linux下使用epool
boost::asio的出现,解决跨平台异步io接口模型不统一等等的这些问题
但是随之问题也出现:asio在使用和学习过程中相对还是有一些使用上的门槛和“坑”
虽说官网上的examples也不少,但是真正能用在“产品”上的几乎寥寥,大家也是在某一个点上进行探讨而不是全局的设计等等
因为涉及的东西真的是千千万万,比如为什么要用到shared_ptr?什么时候要用deadline_timer?还要补习网络协议相关方面的知识
如何优雅的关闭socket?如何维护一个堆栈来规避内存开销和应用层上层线程池逻辑调用?raw_socket、strand、work、timer和io_service各个的关系又是什么?它们有什么使用规则?
头疼的是asio线程间的各种关系,什么时候应该同步,什么时候应该异步等等,asio::async_xxx和raw_socket->async_xxx有什么使用上的注意事项和细节等等
如何处理包序?如何收到预期?如果不够或多了、丢了又该怎么办?
投递read和write的时序?投递多个会怎么样?出错了又会怎么样?超时该如何做?如何安全的shutdown server?
c++0x的部分特性不理解怎么办?如何不是为了用而用?等等等等。。。
回答:
尽在BrinK!
首先:为什么要开源?其实是一种精神,或者一种信仰
感谢能看到这里的各位,其实开源主要是沟通交流和相互学习、能力提升的一种过程
一个好的开发者,并不是偏执而高高在上、不愿意接受新鲜事物的,而是以抱着永远学习和谦虚的态度去做事情,只有这样,才会进步、我想做人也是这个道理
简单的介绍一个这个所谓的“项目”
前面也说到了,BrinK是个基于boost::asio的网络服务端,可能大家都有这个疑问:它具体都能干什么呢?有何优势?我为什么要选用你?
首先、它在使用功能上比较简单,懂网络协议的应该知道,接口上分别有:握手、收、发、出错、超时,在外层看来,它只是一个简单的server
它有什么优势?说实话我也不知道它有什么优势或亮点,也许我本人并不认为它有什么优势,虽然没有优势,但是它使用的东西可不少
BrinK设计理念是分层级的,最下层是raw_tcp/udp,只处理最基本的业务逻辑
整个服务器框架上使用了对象池来做资源伪回收管理,并通过一个线程池来保证同步和“非阻塞“处理
你可以从该项目中学习到的技术点至少有:
1:线程池/对象池原理和机制、资源回收等
2:较良好的C++命名规范和编码规范
3:一些第三方库使用
4:lambda一些技巧和一些C++11使用上的经验
5:同步/异步/资源竞争/调度问题
6:回调函数
7:网络协议相关知识
8:框架方面的知识
非常欢迎任何对此“项目”感兴趣的人投入参与进来,如果你对它感兴趣,那么就加入吧!
如果你发现了有实现不好的地方或者更好的解决方法,请大胆提出,任何形式的BUG或合理的意见建议都会被吸收
目前开发者:
InvXp(我自己)
使用方法:
用vs2013打开sln工程文件编译即可
test文件下为测试客户端
测试: 均由成千上万个Client连接
服务器通过7x24死连接超时测试 服务器通过7x24开关测试 服务器通过7x24收、发、握手、出错测试
目前功能:tcp支持较完整
udp未全部实现,只有框架
TODO也有一些详细的计划