关于RCF中间件的二进制大小

Question

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

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

我使用GCC 4.4.3在一个64位的ubuntu安装.我使用发行版的演示子目录中的下面一行编译了简单的服务器和客户端代码。

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.2MB之间波动。

警钟在响，我用下面三个例子作为我的院子里的棍子：

1. Boost::ASIO:服务器2示例，在发行版中使用bjam编译。得到的代码(去掉后)是176 is 。
2. nginx:一个高度复杂，非常可配置，非常高效的网络服务器.500剥离。
3. 专注于最低限度的中间件解决方案Zero MQ。libzmq 274 k

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

我有两个主要的问题。

1. rpc代码路径的质量。我想要低延迟。
2. 当我开始对我的应用程序进行编码时，二进制代码的增长就围绕着它。

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

“问题”

我想从那些设计实时数据处理系统的人那里得到一些反馈。你能证明这个尺寸合理吗？

"/The问题“

我会考虑其他选择。ZMQ不错，但它依赖于访问，没有SSL，没有提供很多中间件原语，也没有提供命名管道(我需要验证连接进程，命名管道具有安全上下文)

Answer 1

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

您可以将RCF构建为DLL，并将其链接到DLL。在构建DLL时，您需要定义RCF_BUILD_DLL，否则什么都不会导出。

对于一个大概的数字，在VisualWeb2008Build环境中，这将导致一个1.6MB的C++动态链接库。仍然会有一些代码在导入模块中结束，因为RCF的封送处理代码使用模板，模板代码需要内联在标头中，因此不能从DLL导出。

关于你的关切：

(1) RCF是从一开始就设计的，考虑到低延迟，远程调用的关键路径是高度优化的。例如，根本没有内存分配，也没有消息数据的复制。如果您担心，您可以编写一个简单的客户端和服务器，查看每秒可以调用多少个(只需记住使用发布版本)。有关更多信息，请查看用户指南中的用户指南部分

(2)与任何库一样，当您将其构建到应用程序中时，会有一些预先的开销。但在那之后不会有任何“持续”的开销。