关于RCF中间件二进制大小

Question

RCF是用于RPC和分布式消息传递的库/框架。我喜欢RCF框架，原因如下

1. 在线服务 - 接口 - rpc调用规范（即没有单独编译IDL）。
2. C10K设计风格（windows IOCP或boost ASIO的顶层）。
3. 支持windows命名管道和unix域套接字（我绝对不能妥协）。
4. SSL
5. 消息传递范例，双向，单向，客户端回调，单向批量。
6. 协议缓冲支持（因为我认为我可以坚持使用内置序列化）。
7. 发布/订阅功能。

我在64位ubuntu安装上使用GCC 4.4.3。我使用分发的demo子目录中的以下行编译普通服务器和客户端代码。

g++ -O3 -DRCF_USE_BOOST_ASIO Client.cpp ../src/RCF/RCF.cpp -I ../../Boost/ -I ../include/ -lpthread ../../Boost/lib/libboost_system.a -s

生成的客户端和服务器二进制文件在 1.7到2.2兆字节之间波动。

警钟响了;我使用以下三个例子作为我的院子棒：

1. Boost :: ASIO：使用bjam在发行版中编译的服务器2示例。生成的代码被剥离， 176kb 。
2. nginx：一个高度复杂，可配置，非常高效的Web服务器。 500kb剥离。
3. Trandsport Channel专注于最小的中间件解决方案Zero MQ。 libzmq 274k

我已经编写了自己的生产RPC /中间件，我正在进入一个我认为我只会写另一个以满足我的需求的阶段，在Boost之上进行分层。但我不想这样做。我喜欢RCF的设计，它符合我的需求。但是，我无法证明简单程序的二进制大小，它不应该产生如此庞大的二进制文件。

我有两个主要问题。

1. rpc的代码路径的质量。我想要低延迟。
2. 当我开始编写我的应用程序时，二进制文件的增长。

一个合理的解释是该库不是为模块化而设计的，而是预先实例化所有内容。

[“问题”]

我想得到一些人的反馈，他们根据我的担忧设计了实时数据处理系统。你能证明这个尺寸吗？

[“/问题”]

我会考虑其他选择。 ZMQ很不错，但它的附带依赖性，错过了SSL，没有提供很多中间件原语，也没有提供命名管道（我需要验证连接进程，命名管道有安全上下文）

Answer 1

您的命令行正在做的是将RCF静态编译到服务器和客户端可执行文件中。这使得构建过程变得简单，但也意味着两个可执行文件都带有他们自己的RCF副本。 RCF 1.3中有超过60000行代码，因此肯定会对可执行文件大小产生影响。

您可以将RCF构建到DLL中，然后链接到它。在构建DLL时，您需要定义RCF_BUILD_DLL，否则不会导出任何内容。

对于一个棒球场图，在我拥有的Visual C ++ 2008构建环境中，这会产生1.6 MB的DLL。仍然会有一些代码最终出现在导入模块中，因为RCF的编组代码使用模板，模板化代码需要在头文件中内联，因此无法从DLL中导出。

关注您的问题：

（1）RCF从一开始就考虑了低延迟，并且远程调用的关键路径得到了高度优化。例如，根本没有内存分配，也没有复制消息数据。如果你担心，你可以编写一个简单的客户端和服务器，看看你每秒可以进行多少次调用（只记得使用发布版本）。有关详情，请查看Performance

中的User Guide部分

（2）与任何库一样，当您将其构建到应用程序中时，会有一些前期大小的开销。但此后不会有任何“持续”的开销。