发布一个基于 Reactor 模式的 C++ 网络库
Shuo Chen
半年前我写了一篇《学之者生，用之者死——ACE历史与简评》，其中提到“我心目中理想的网络库”的样子：
* 线程安全，支持多核多线程
* 不考虑可移植性，不跨平台，只支持 Linux，不支持 Windows。
* IO multiplexing 使用 poll 和 epoll。 （poll 是为了在开发库本身时便于调试 IO 事件）
* 主要支持 x86-64，兼顾 IA32
* 不支持 UDP，只支持 TCP
* 不支持 IPv6，只支持 IPv4
* 不考虑广域网应用，只考虑局域网
* 只支持一种使用模式：non-blocking IO + one event loop per thread，不考虑阻塞 IO
* API 简单易用，只暴露具体类和标准库里的类，不使用 non-trivial templates，也不使用虚函数
* 只满足常用需求的 90%，不面面俱到，必要的时候以 app 来适应 lib
* 只做 library，不做成 framework
* 争取全部代码在 5000 行以内（不含测试）
muduo 的主体内容在 5 月底已经基本完成，现在我把它开源。
从架构上讲，muduo 没有多少新意，它就是一个 IO 多路复用的事件处理库，熟悉 reactor 模式的人一看就明白。
在实用上，我还没有用它实现复杂的应用（我有一些打算，比如实现 protobuf-rpc）。
这个库也没有以高并发高吞吐为目标，它的目标是清晰简洁，容易理解并使用，且性能过得去 (并发数达到 50k)。
在细节上，我花了比较多的精力从设计上保证事件回调的安全，不会提前释放对象，也不会有泄漏，而且做到线程安全。
更多的介绍（包括对象生命期的设定）与下载方式见： http://blog.csdn.net/Solstice/archive/2010/08/29/5848547.aspx
woo
Linker M Lin
On Sep 1, 12:08 pm, woo <woosi...@gmail.com> wrote:
> 我觉得，你可以考虑看看libevent
> On 20:35 Tue 31 Aug , Shuo Chen wrote:
>
> > Muduo 是我在业余时间编写的基于 Reactor 模式的 C++ 网络库，适用于 Linux 平台，支持多线程。
> > 半年前我写了一篇《学之者生，用之者死----ACE历史与简评》，其中提到"我心目中理想的网络库"的样子：
kelviN
On Sep 1, 11:35 am, Shuo Chen <giantc...@gmail.com> wrote:
> Muduo 是我在业余时间编写的基于 Reactor 模式的 C++ 网络库，适用于 Linux 平台，支持多线程。
> 半年前我写了一篇《学之者生，用之者死----ACE历史与简评》，其中提到"我心目中理想的网络库"的样子：
qiaojie
Shuo Chen
2.0.6 中。
libev 不是一个完整的网路库，它功能主要是提供一个高效的 IO 事件循环，如果用它来编写网络程序的话需要自己补充写很多代码。
asio 是基于 proactor 模式的 C++ 网络库（主体部分有 4 万多行代码），如果你喜欢 proactor 风格，那么用它也挺
好。
这三个库都是跨平台的，因此增加了不少复杂性。
muduo 试图把 libevent 的便利性带到 C++ 语言中，并利用 C++ 语言的特性来简化网络开发（特别是资源管理这块）。
在编写 muduo 时，我尝试过用 C++ 封装 libevent ，但是感觉用起来没有自己写的库那么顺手。
Shuo Chen
Shuo Chen
是为方便我在家编写分布式程序（eg. 不需要支持 Windows/IPv6）。
为此，我需要一个用着顺手且靠得住的网络库作为平台，于是就有了 muduo。
HaoPeiQiang
--
Tinyfool的开发日记 http://www.tinydust.net/dev/
代码中国网 http://www.codechina.org
myTwitter: http://twitter.com/tinyfool
jinhu wang
HaoPeiQiang
Shuo Chen
On Sep 1, 2:55 pm, HaoPeiQiang <HaoPeiQi...@gmail.com> wrote:
> 我也很好奇这个
>
> 2010/9/1 jinhu wang <wangjinhu...@gmail.com>
>
>
>
>
>
> > muduo的名字是怎么来的？
>
> > 在 2010年9月1日 下午2:47，Shuo Chen <giantc...@gmail.com>写道：
>
> > 简单地说，是适应我自己的需求。正如http://code.google.com/p/muduo/所列，我的意图并不是写一个通用的网络库，而
jinhu wang
jinhu wang
我的感觉是：每次看到一个新概念都会先头大半天，概念的叠加提高了学习的门槛，对于我来说，这个库还是复杂了些。
不过从自用的角度出发，应该是一个很好的东西。
jigsaw
sagasw
不做profiling就可以知道哪个地方一定会浪费？
------------------------------------------
blog: http://sunxiunan.com/
C++, Lua, living in Dalian
http://twitter.com/sagasw
------------------------------------------
2010/9/3 jigsaw <jig...@gmail.com>:
jinhu wang
我觉得学习价值还是有的。
缺点是上下文依赖太多。
bronco
jinhu wang
Hongzhang Liu
Shuo Chen
http://blog.csdn.net/Solstice/archive/2010/09/04/5863411.aspx
On Sep 1, 11:35 am, Shuo Chen <giantc...@gmail.com> wrote:
> Muduo 是我在业余时间编写的基于 Reactor 模式的 C++ 网络库，适用于 Linux 平台，支持多线程。
> 半年前我写了一篇《学之者生，用之者死----ACE历史与简评》，其中提到"我心目中理想的网络库"的样子：
Shuo Chen
On Sep 4, 4:12 pm, Hongzhang Liu <hongzhang....@gmail.com> wrote:
> 天将以夫子为木铎
>
> 野心很大啊
>
> 2010/9/1 jinhu wang <wangjinhu...@gmail.com>
>
>
>
> > muduo的名字是怎么来的？
>
> > 在 2010年9月1日 下午2:47，Shuo Chen <giantc...@gmail.com>写道：
>
> > 简单地说，是适应我自己的需求。正如http://code.google.com/p/muduo/所列，我的意图并不是写一个通用的网络库，而
jigsaw
___-
用cpp写这种体积小而运行速度快产品没有优势。要简单的话有perl，要快的话有c。
而且这种基于poll的产品，既要尽量快，又要尽量少占cpu。因为poll很容易写成很占cpu的loop。如果持续占用超过5%的cpu，那肯定是
没法实际使用的，除非你的应用是跑10Gbps的。
你写个最简单的tcp发送接收试试看，一个线程就够，死循环发送和接收，很轻松跑满1G的网卡，吞吐量肯定也比asio大，cpu也一直99%，但是这
样做有意义吗？
qiaojie
Shuo Chen
http://blog.csdn.net/Solstice/archive/2010/09/05/5864889.aspx
Shuo Chen
上只能跑 1 个或 2 个线程，测不出多线程的加速比。
另外，现在的 CPU 已经快到一个线程一个 TCP 连接就能很轻松地把千兆以太网的带宽跑满，所以用两台机器用 ping pong 方法测出来的
吞吐量不超过 1Gb/s ，无论连接数怎么变化和线程数怎么变化。
这样的测试结果没多大参考价值，因为过早地触到了物理界限。（或许 CPU 占用率有一点用。）
On Sep 5, 2:45 pm, qiaojie <qiao...@gmail.com> wrote:
> 这位老兄，没做过测试就不要乱下结论，你怎么知道他的程序CPU占用率就比asio高很多了？
> 而且你的话也很矛盾，一会说"asio快到任何人都望尘莫及"，一会又说"cpp速度没c快"，那你告诉我asio用什么开发的？
>
> 当然我也觉得楼主的测试有些草率和不严谨，首先不应该在同一台机器上测试，本机测试的话TCP并不通过网卡，而是直接在内存里通讯了，这样不可能准确的得到IO 吞吐量，其次应该补充一下两个测试中所用的IO模型，以及对瓶颈的分析。
qiaojie
jigsaw
jigsaw
吞吐量不超过 1Gb/s ，无论连接数怎么变化和线程数怎么变化。
Zhang Jiawei
Zhang Jiawei
Milo Yip
>> slice是非常宝贵的资源，当你见识过跑几百万并发连接的服务器时就知道了。
* 不考虑广域网应用，只考虑局域网
不是所有應用都要開一百萬個連接吧。對於局域網的分佈式應用，連接數等於局域網內的節點數目己經足夠吧?
--
Milo Yip
Twitter @miloyip
http://www.cnblogs.com/miloyip/
http://miloyip.seezone.net/
jigsaw
tony.jiao
Shuo Chen
在 IO 事件处理效率方面，muduo 与 libevent2 总体比较接近，各擅胜场。在并发量特别大的情况下（大于 30k），muduo 略
微占优。
http://blog.csdn.net/Solstice/archive/2010/09/08/5869801.aspx
jinhu wang
Reactor模式能理解成就是bridge模式的一个示例吧？
Shuo Chen
也不一定要用继承和虚函数来实现。bridge 是一个抽象的面向对象的设计模式。跟 reactor 没啥关系。
On Sep 16, 1:48 pm, jinhu wang <wangjinhu...@gmail.com> wrote:
> Reactor模式能理解成就是bridge模式的一个示例吧？
>
jinhu wang
其次，处理事件的通行方式一般就是委托（bridge）和继承（template）。
所以我说reactor只是一种泛化了的bridge模式，即便跟OO划清界限。
chuang
Shuo Chen
RefinedAbstraction，哪个是 Implementor，哪个是 ConcreteImplementor ？
reactor 的核心功能是用一个事件循环来处理多个文件描述符上的读写事件，并且支持定时器操作。我没有看出 bridge 与这个功能有任何具体
的联系。
On Sep 16, 3:15 pm, jinhu wang <wangjinhu...@gmail.com> wrote:
> 首先：设计模式没说是OO专有的吧：）
> 其次，处理事件的通行方式一般就是委托（bridge）和继承（template）。
> 所以我说reactor只是一种泛化了的bridge模式，即便跟OO划清界限。
>
jinhu wang
jinhu wang
当专家处理特定问题的时候，如果复用了已有的一种成熟方法，那么这个方法就可以称其为模式。
23种OO设计模式只能说是老大们总结出来已有的模式来指导OO设计的。或者说是一种反向证明OO合理的一个论文集。
模式是死的，人是活的。
Shuo Chen
"桥"的另一头是 Implementor，那一头的桥墩叫 ConcreteImplementor。
以上 4 个部件构成了"桥接"模式。
http://en.wikipedia.org/wiki/Bridge_pattern
On Sep 16, 4:01 pm, jinhu wang <wangjinhu...@gmail.com> wrote:
> Abstraction是什么东西？
>
Mikster.Z
chuang
jinhu wang
jinhu wang
up duan
jinhu wang
jinhu wang
从行为角度看它是：观察者、职责链、中介者的组合体；
从结构角度看：不说桥接了，总之是将实现体引出去的影子，呵呵。
up duan
没必要僵化一些概念，我也是在07年的时候看到OSE architecture user's guide的design patterns这一章节后才跳离被那经典的束缚的。虽然reactor出自另一本书，但是你不得不承认它是处理并发的一个典型的设计模式。当看到一大堆handler的时候，很容易联想到它：）
jinhu wang
张慧聪
Walkley He
Shuo Chen
另外一个文件描述符通常只有一个 handler，这也不完全符合 subject 与 observer 的一对多关系。
你说的另外两个模式在 reactor 里有哪些具体体现？
比如 handler 里有没有 successor？
又比如 reactor 里谁是 Mediator？谁是 ConcreteMediator？又有哪些 Colleague classes？
On Sep 16, 4:59 pm, jinhu wang <wangjinhu...@gmail.com> wrote:
> 宏观角度看，Reactor还是自成一体了，
> 从行为角度看它是：观察者、职责链、中介者的组合体；
> 从结构角度看：不说桥接了，总之是将实现体引出去的影子，呵呵。
>
qiaojie
jinhu wang
Reactor本身是用以处理多路事件分离的一个模式，侧重点在于
- 多路事件并发
- 事件的1:N处理（对于fd的处理，往往是1：1）
职责链在事件的1：N处理的时候会出现它的影子，链式操作往往引入的是油漆匠算法，所以也是根据情况决定，
中介者的话reactor应该更明显了，例如两个server上的reactor之间的handler们，都是通过reactor来互动的。抽象提炼一下就是跨平台的另一种通信模式。
至于桥接，高度抽象一下的话，多路事件分离的实现体可以兼顾多操作系统，在高度一点，可以兼顾不同的事件同步接口。另外fd的handler可以很轻松的定制注册到reactor中，这本身其实也是桥接的影子。
另外我的以下理解不知是否极端：UML是设计师的语言，而设计模式是设计交流的关键词汇。从高度抽象向实现细节的过程中，一些模式渐渐就能呈现出来。从已有的源码反向工程去映照设计，也总能找到设计模式（包括开始没想到的设计）的踪迹。
殷远超
Shuo Chen
我将会写一系列文章，介绍用 muduo 网络库完成常见的 TCP
网络编程任务。这些例子都比较简单，逻辑不复杂，代码也很短，适合摘取关键部分放到博客上。其中一些有一定的代表性与针对性，比如“如何传输完整的文件”估计是网络编程的初学者经常遇到的问题。
http://blog.csdn.net/Solstice/archive/2011/02/02/6171831.aspx
> From: Shuo Chen <giantc...@gmail.com>
> Date: Sep 8 2010, 1:12 am
> Subject: 发布一个基于 Reactor 模式的 C++ 网络库
> To: TopLanguage
>
>
> 击鼓传花：对比 muduo 与 libevent2 的事件处理效率
>
> 在 IO 事件处理效率方面，muduo 与 libevent2 总体比较接近，各擅胜场。在并发量特别大的情况下（大于 30k），muduo
> 略
> 微占优。
>
> http://blog.csdn.net/Solstice/archive/2010/09/08/5869801.aspx
>
> On Sep 5, 6:58 pm, Shuo Chen <giantc...@gmail.com> wrote:
>
>> 继续测试，ping pong 测试表明，muduo 吞吐量比 libevent2 高 18% 以上。
>
>>http://blog.csdn.net/Solstice/archive/2010/09/05/5864889.aspx
>
>> On Sep 4, 4:35 pm, Shuo Chen <giantc...@gmail.com> wrote:
>
>> > 出乎我的意料，ping pong 测试表明，muduo 吞吐量比 boost.asio 高 15% 以上。
>
>> >http://blog.csdn.net/Solstice/archive/2010/09/04/5863411.aspx
>
>> > On Sep 1, 11:35 am, Shuo Chen <giantc...@gmail.com> wrote:
>
>> > > Muduo 是我在业余时间编写的基于Reactor模式的 C++ 网络库，适用于 Linux 平台，支持多线程。
Shuo Chen
这是《Muduo 网络编程示例》系列的第一篇文章。本文将介绍五个简单 TCP 网络服务协议的 muduo 实现，包括 echo、
discard、chargen、daytime、time 等，以及 time 协议的客户端。以上五个协议使用不同的端口，可以放到同一个进程中实
现，且不必使用多线程。
http://blog.csdn.net/Solstice/archive/2011/02/02/6171905.aspx
Shuo Chen
这是《Muduo 网络编程示例》系列的第二篇文章。 本文讲介绍一个与 Boost.Asio 的示例代码中的聊天服务器功能类似的网络服务程序，包
括客户端与服务端的 muduo 实现。这个例子的主要目的是介绍如何处理分包，并初步涉及 Muduo 的多线程功能。
http://blog.csdn.net/Solstice/archive/2011/02/04/6172391.aspx