基于boost::asio的网络socket服务端
一直以来，我们总是纠结网络服务器开发模型、线程、效率、优化等等
相对比较好一点的理论上大的概念都知道Win下使用IOCP、Linux下使用epoll
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也有一些详细的计划
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent