关于RCF中间件二进制大小 [英] On RCF Middleware Binary Size

问题描述

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

RCF is a library/framework for RPC and distributed messaging. I like the RCF framework for the following reasons

1. 在line service - interface - rpc调用规范中（即没有单独编译IDL） 。


2. C10K设计风格（windows on IOCP或boost ASIO的图层）。


3. 支持Windows命名管道和unix域套接字（我绝对不能妥协。）


4. SSL。


5. 消息传递范式，2路，1路，客户端回呼，1路批处理。


6. 协议缓冲区支持（我认为我可以坚持使用内置序列化）。


7. 发布/订阅功能。
   

1. in line service - interface - rpc call specification (i.e., no separate compilation of an IDL).
2. C10K design style (layers ontop of windows IOCP or boost ASIO).
3. supports windows named pipes and unix domain sockets (I absolutely cannot compromise on this).
4. SSL.
5. Messaging paradigms, 2-way, 1-way, client-callback, 1-way batched.
6. protocol buffers support (tho I think I can stick with the built-in-serialization).
7. publish/subscribe functionality.

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

I am using GCC 4.4.3 on a 64-bit ubuntu install. I compile the trivial server and client code using the following line in the demo subdirectory of the distribution.

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兆字节之间波动。

The resulting client and server binaries fluctuate between 1.7 to 2.2 megabytes.

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

Alarm bells are ringing; I use the following three examples as my yard sticks:

1. Boost :: ASIO：server 2示例使用bjam编译版本。


2. nginx：一个高度复杂，可配置，非常高效的网络服务器。 500kb stripped 。


3. Trandsport频道专注于最小中间件解决方案零MQ。 libzmq 274k

1. Boost::ASIO: server 2 example compiled in release version using bjam. The resulting code , stripped, is 176kb.
2. nginx: A highly complex, very configureable, very efficient web-server. 500kb stripped.
3. Trandsport Channel focused minimal middleware solution Zero MQ. libzmq 274k

我写了自己的生产RPC /中间件，我想我会写另一个，以满足我的需要，分层在Boost的顶部。但我不想这样做。我喜欢RCF的设计，它满足我的需要。然而，我不能证明简单程序的二进制大小，它不应该产生这样大量的二进制文件。

I have written my own production RPC/middleware and I'm getting to a stage where I'm thinking I'll just write another one to meet my needs, layering on top of Boost. But I do not want to do this. I like RCF's design, it meets my needs. However, I can't justify the binary size of the simple programs, it should not produce such massive binaries.

我有两个主要问题。

1. rpc的代码路径的质量。我想要低延迟。


2. 随着我开始编写我的应用程序的二进制文件的增长。

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

A reasonable explanation is that the library isn't designed for modularity, and instantiates everything upfront.

[问题]

设计实时数据处理系统的人对我的关注。你能证明这个尺寸吗？

I'd like some feedback from folks who design real-time data-processing systems on my concerns. Could you justify this size ?

[/问题]

ZMQ是好的，但它的一个依赖的依赖，缺少SSL，不提供很多中间件原语，不提供命名管道（我需要验证连接进程，命名管道有安全上下文）

I'd consider alternatives. ZMQ is nice, but its an aditional dependancy, misses SSL, doesn't provide a lot of middleware primitives, and doesn't provide named pipes (I need to verify connecting processes, and named pipes have security contexts)

推荐答案

您的命令行所做的是将RCF静态地编译到服务器和客户端可执行文件中。这使得构建过程简单，但也意味着两个可执行文件都携带他们自己的RCF副本。

What your command line is doing, is compiling RCF statically into the server and client executables. That makes the build process simple, but also means that both executables are carrying around their own copy of RCF. There are over 60000 lines of code in RCF 1.3, so it will definitely have an impact on executable size.

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

You can build RCF into a DLL, and link to it instead. You'll need to define RCF_BUILD_DLL when building the DLL, or nothing will be exported.

对于一个ballpark图，在Visual C ++ 2008构建环境中，在1.6 MB DLL。仍然有一些代码在导入模块中结束，因为RCF的编组代码使用模板和模板代码需要在头文件中内联，所以不能从DLL导出。

For a ballpark figure, on a Visual C++ 2008 build environment I have, this results in a 1.6 MB DLL. There will still be some code that ends up in the importing module, as RCF's marshaling code uses templates and templated code needs to be inlined in headers, so can't be exported from the DLL.

关于您的问题：

（1）RCF的设计始于低延迟，远程调用的关键路径是高度优化。没有内存分配，例如，没有复制消息数据。如果你担心，你可以编写一个简单的客户端和服务器，并看到每秒可以做出几千个调用（只记得使用发布版本）。有关详情，请查看效果部分的用户指南

(1) RCF was designed from the start with low-latency in mind, and the critical path for a remote call is highly optimized. There are no memory allocations at all for instance, and no copying of message data. If you're worried, you can write a simple client and server and see how many thousands of calls you can make per second (just remember to use a release build). For more information, have a look at the Performance section in the User Guide

（2）任何库，当你构建到你的应用程序有一些前面大小开销。但之后不会有任何持续的开销。

(2) As with any library, there is some up front size overhead when you build it into your application. But there won't be any 'ongoing' overhead after that.

这篇关于关于RCF中间件二进制大小的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！