RPC、套接字和性能注意事项
我有两台机器在同一子网中。我想尽快在两台机器之间交换对象。它使用 g++，并且运行在 Debian/Ubuntu 上。这些机器的流量和 CPU 负载很高。
一种方法是通过套接字将对象的压缩序列化作为二进制数据包发送（使用 Google 协议缓冲区进行 ex 编码）。
CORBA 似乎对此杀伤力太大
我读了一些有关 ONC-RPC 和 Sun RPC 的文章
Boost 有一个高效的库吗？
我相信您还有其他想法。您将如何保证 2011 年的最佳响应时间...我可以放弃一点点响应时间以获得标准解决方案。
I have two machines in the same subnet. I want to exchange objects between the two machines as quickly as possible. It is using g++ and it is on Debian/Ubuntu. The machines are loaded in traffic and CPU.
One way is to send a compressed serialisation of the object over sockets as binary packets (using Google protocol buffers for the encoding for ex).
CORBA seems an overkill for this
I read some articles about ONC-RPC and Sun RPC
does Boost have an efficient library for this ?
I am sure you have other ideas. How would you do it to garantee the best response time in 2011... I am OK to give up just a little tiny bit on response time to get a standard solution.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您可以将 Google protobuf 与 Boost.ASIO 结合起来进行序列化处理实际的 I/O。这应该在性能和实施时间之间提供良好的平衡。
You could combine Google protobuf for serialization with Boost.ASIO to handle the actual I/O. That should offer a good balance between performance and implementation time.
Zeromq 的人已经尝试使用 Linux 实时内核来保证低延迟。正如您所看到的，为了这种保证，必须牺牲大量的平均延迟。根据应用程序，这可能是必要的权衡。
http://www.zeromq.org/results:rt-tests-v031
The Zeromq people have experimented with using a Linux realtime kernel to guarantee low latency. As you can see, a big amount of average latency has to be sacrificed for this guarantee. Depending on the application it may be a necessary tradeoff.
http://www.zeromq.org/results:rt-tests-v031
当您说您想“尽快在两台机器之间交换对象”时，听起来您感兴趣的是尽可能限制网络带宽。如果是这种情况，您可以考虑使用 FAST 协议。
缩写 FAST 的正式意思是“FIX Adapted for Streaming”，这意味着它最适合 FIX 协议，但事实并非如此。 FAST 实际上可以与任何协议一起使用。
FAST 编码的数据包可能非常小，良好的实现将在编码和解码中使用有限的 CPU 资源。需要权衡的是，FAST 协议并不是世界上最容易被人类理解的东西，而且代码也很难正确编写。有可用的开源产品实现，它们可能适合也可能不适合您的需求。 C++ 的此类实现之一是 QuickFAST。
When you say you want to "exchange objects between the two machines as quickly as possible" it sounds like what your'e interested in is limiting network bandwidth as much as possible. If that's the case, you might consider using the FAST protocol.
The acronym FAST officially means "FIX Adapted for Streaming" which implies that it is best suited to the FIX protocol, but this really isn't true. FAST can be used with really any protocol.
FAST-encoded packets can be extremely small, and a good implementation will use a limited amount of CPU resources in the encoding and decoding. The tradeoff is the FAST protocol isn't the easiest thing in the world to grok by a human, and the code can be quite tricky to get right. There are open source products implementations available which may or may not be appropriate for your needs. One such implementation for C++ is QuickFAST.