大型c/s结构框架，基于boost.asio，有源码及教程

st_asio_wrapper，目前最新稳定版本2.0
源码下载：http://download.csdn.net/detail/yang79tao/4543258
教程共三篇（第一篇）：http://blog.csdn.net/yang79tao/article/details/7724514

主要功能：
虽然名字叫wrapper，但它不仅仅是包装boost.asio，而是实现了一个c/s结构框架；
最简单的开发只需要在客户端申明一个st_client对象，在服务端申明一个st_server对象，然后分别调用stat_service即可，当有数据需要发送时，调用send_msg发送数据，当有数据收到时，默认会输出到屏幕，二次开发者只需要重写on_msg_handle虚函数，即可自己处理消息，此时就已经实现了一个支持成千上万的c/s结构的服务端加客户端。

具体说来：
完全异步加多线程，线程数量可配置（宏），如果想要单线程，则配置一个线程即可；
数据透明传输，即自动打包解包，自动解决数据分包粘包乱序等问题；
支持自定义打包解包器，且可运行时修改；
服务端自动管理所有客户端状态；
服务端支持对象池；
服务端支持垃圾对象（已关闭的客户端对象）回收；
两端都带输入输出缓存；
跨平台，支持ipv6；

注：大量使用了c++0x特性，其中有个rang-based loop for新语法，在vc2010都编译不过（需要vc2012）；但所有用到的特性都只是语法糖，相信大家很容易修改为原来的基本语法；
gcc则没有问题（我只在4.6.3及其以上版本中试过）；
需要编译boost的system和thread库。建议使用1.50.0及其以上的boost版本，低版本的我没试过，我相信，只要编译能过，应该都能使用。

101 个解决方案

#1

难道有沙发坐，顶一个先，不怎么用boost，

#2

谢谢帅哥分享~
收藏以后看~~

#3

搓，抢我沙发

#4

该回复于2012-09-03 11:13:00被版主删除

#5

感谢分享~

#6

优势在哪里，又是重复造的*？

#7

支持一下吧

#8

该回复于2012-09-03 14:05:57被版主删除

#9

造*也是有意义的，可以认为整个系统就是由不同层次大大小小的*支撑起来的，能把你自己的业务逻辑封装成*也是一种本事

#10

    感觉好新啊！正在使用boost 1.42呢。

#11

不要重复造*,这话是谁说的?

#12

重复造*？意思是已经有类似的封装了，还是说boost.asio不需要封装了？
如果已经有人封装了，那是他的事，相信每个人的封装特点、重点、风格以及能完成的功能都是不相同的。
如果你觉得boost.asio不需要封装，那你就直接用boost.asio吧。

我这个封装主要是业务上的。

#13

楼主是打技术广告的~~~

#14

该回复于2012-09-04 08:42:07被版主删除

#15

支持分享的精神

#16

该回复于2012-09-04 08:44:16被版主删除

#17

该回复于2012-09-04 08:27:08被版主删除

#18

这个要顶啊。。。

#19

该回复于2012-09-04 09:08:07被版主删除

#20

c/s程序框架?

#21

支持一个，有demo就更好了

#22

不错，支持一下。
下了以后研究下学习boost.asio也不错。
网络模块的确很难统一，因为每个业务都有每个业务的特点

#23

期待测试报告

#24

感谢楼主分享！

#25

支持!

#26

该回复于2012-09-04 13:11:18被版主删除

#27

该回复于2016-10-14 16:04:31被管理员删除

#28

又是一骗子，只提供一些头文件，然后要cpp文件，估计得掏钱。

#29

该回复于2012-09-04 13:49:07被版主删除

#30

引用 23 楼  的回复:

期待测试报告

#31

#32

引用 21 楼  的回复:

支持一个，有demo就更好了

当然有demo，include文件夹下就是类库所有代码，asio_client和asio_server文件夹下就就是两个demo；在vc下，创建两个控制台工程，把asio_client.cpp、asio_server.cpp和echo_server.h分别添加到两个工程，编译即可。

在linux下面就直接g++吧，只需要编译asio_client.cpp和asio_server.cpp即可，连接boost_system和boost_thread库。

至于测试报告，一直没有适合的环境来测试。

至于28楼，大家请忽略，不懂没有错，出来误导就不好，丢人现眼。本来我不想理他，但担心某些初学者受到他的回复的影响，所以还是回一下，只是希望真正需要它的人能用得上它，否则我不白做这个库了吗。

#33

引用 30 楼  的回复:

引用 23 楼  的回复:
期待测试报告

希望能提供详细的测试结果, 例如在单纯接收1024K每包, 处理过程是直接跳过, 不回复, 测试出最大接收和处理量等的结果
能否跑满socket最大值, CPU占用率等的数据, 每秒一共可处理多少? 在N个线程HandleMsg的时候, 每个线程每秒handle多少个msg等

#34

这个嘛，正在做，但测试环境我这边不是是wifi的。
我会放出性能测试代码，大家自己测。

#35

这个嘛，正在做，但测试环境我这边是wifi的。
我会放出性能测试代码，大家自己测。

#36

赚分下载东西额。。。。你懂得、、、、

#37

异步多线程和同步多线程的区别在于线程的创建与关闭开销，如果忽略这点，同步的设计其实比异步的更好用。

#38

该回复于2012-09-05 11:31:20被版主删除

#39

该回复于2012-09-05 13:50:39被版主删除

#40

该回复于2012-09-05 14:03:00被版主删除

#41

引用 35 楼  的回复:

这个嘛，正在做，但测试环境我这边是wifi的。
我会放出性能测试代码，大家自己测。

网络的传送效率是不需要测试的了, 既然你是用boost库. 直接找台有多个CPU的例如i7, 本机跑, 模拟几十至几千个客户端, 客户端不停的向服务器请求, 服务器每秒共处理多少请求就可以了. 

#42

引用 37 楼  的回复:

异步多线程和同步多线程的区别在于线程的创建与关闭开销，如果忽略这点，同步的设计其实比异步的更好用。

同步和异步的不同之处, 在于业务处理过程是存在区别的, 假如业务处理过程都是一至, 一样消耗1ms的话, 采用单线程, 多进程的模式, 是没有问题的. 但假如其中某一两个业务存在1s的耗时, 那么同步就会无办法为其他客户端服务了. 即使是多进程, 也会导致某一个进程内的所有客户端都得要被卡住1s. 

而且, LINUX, 进程跟线程概念和实现貌似是一至的, 但windows不是, 线程切换速度比进程切换速度要快得多. 多线程是可以做到只要有空闲的线程, 那么肯定可以开始新的处理

#43

今天我写了一个性能测试程序在本机运行，环境如下：
ubuntu LTS 12.04 64bit
Intel Pentium Dual CPU E2160 1.80G
2G RAM

32个客户端（st_asio_wrapper里面的客户端，每个客户端一个连接），不停的向服务端发送数据，每个包长1028，每个客户端总共发送1024个包，服务端把收到的消息再发送回去，客户端从开始发送直到所有数据接收完毕，平均耗时850毫秒（每个连接数据量为2105344=2M）。

我没办法测试客户端很多的情况，比如成千上万的客户端，因为st_asio_wrapper里面的每个客户端类（st_client）至少要创建2个线程，必须得重新专门的写一个客户端来测试。

最近我会放出我的性能测试程序，大家有兴趣的可以帮我试试服务端的并发性能怎样，方法推荐：用我的性能测试服务端加上你自己写一个客户端（这个客户端像服务端一样管理大量的连接，连接可以用st_socket类），创建大量连接，然后在每个连接上发送数据。

#44

引用 43 楼  的回复:

今天我写了一个性能测试程序在本机运行，环境如下：
ubuntu LTS 12.04 64bit
Intel Pentium Dual CPU E2160 1.80G
2G RAM

32个客户端（st_asio_wrapper里面的客户端，每个客户端一个连接），不停的向服务端发送数据，每个包长1028，每个客户端总共发送1024个包，服务端把收到的消息再发送回去，客户端从开始发送直到所……

服务器的CPU占用率是? 目前来说, 32个客户端, 分别发送2MB和接收2MB, 大概就一共上传速度为64MB, 下传速度为64MB. 假如你的机器好点, 估计还是可以达到SOCKET的峰值的.
不过希望能够弄个小一点的数据, 大概在1KB以下就可以了, 服务器的性能指标主要不是接收流, 是处理脉冲式的请求的速度, 高效的流处理服务器架构不是这样子的. 然后看看每秒每个线程处理多少次, 数据回复或者不回复都可以.

#45

cs是吗?

#46

前面说错了，平均耗时在250-600之间，我看成最大耗时了，试过很多次。

我就是苦于没有时间专门写个客户端（建立很多连接）来测试，因为我的st_client无法在同一机器上创建太实例（前面说了，是线程的问题）。

我想就算我写了这么一个客户端，发起成千上万的连接，那也不能测出真实的结果，因为这个客户端的效率没办法保证（要想实现到最好，可能就跟服务端差不多了），最好的办法是找成千上万的电脑-_-

我觉得如果只是测“众多连接中，随机的极少几个连接发送数据”这种情况，基本上不用测了，因为这就是epoll优于其它模式的体现之一。

所以，归根结底，是不是还是要测满负载的情况，而这种情况我上面的测试工程好像已经做了。

另外，在本机测试，只能测试IO调度的情况，速度测试结果根本不反应真实情况，所以还得找不同的电脑来做。还需要使用者去做，不过我会放出测试工程。

#47

支持lz的共享精神，这种业务框架很实用的

#48

引用 42 楼  的回复:

引用 37 楼 的回复:
但假如其中某一两个业务存在1s的耗时, 那么同步就会无办法为其他客户端服务了. 

当前这个线程无法为这个业务继续服务了，同步多线程的设计，就是一个任务针对一个线程，该等待的仍然需要等待。

异步分离了原本整体的一个任务，这样的设计并不是在任何时候都是最佳的，比如用tcp传输文件。

#49

引用 46 楼  的回复:

我想就算我写了这么一个客户端，发起成千上万的连接，那也不能测出真实的结果，因为这个客户端的效率没办法保证（要想实现到最好，可能就跟服务端差不多了），最好的办法是找成千上万的电脑……

for()
{
connect
}
就可以了，如果服务器性能一般 2台电脑就够你服务器受得了。

cpu的速度，肯定比你的处理速度快，而且要看你的Listen队列的默认长度。

按照LZ的测试 每秒能传输100M？是小型局域网吗？

#50

一个任务开一个线程？
服务端有成千上万的send和recv任务，不大可能吧？

另外，异步起一个电容的作用，如果处理速度慢与数据接收速度，那等待是肯定的，但如果有下面的情况：
数据接收速度是一个正弦曲线，当在最高处时，处理速度慢于接收速度，但在最低处时，处理速度又快于接收速度，此时异步操作将起到一个类型电容的作用（处理速度会达到一条类似直线的速度），会大大加快吞吐量。

当然，这会要求一个数据接收缓存，st_asio_wrapper有这个功能，包括上面说到的电容功能及接收缓存。