c++ - Protocol Buffer 和实际传输选项 - 套接字或中间件

Question

我正在开发一个客户端/服务器应用程序，我正在为其评估通信层的几个选项。

作为此通信框架的一部分，我正在考虑使用谷歌的 Protocol Buffer (PB) 来表示传输数据，而不是重新发明我自己的二进制结构。

现在开始实际的传输，我想知道是否应该使用普通套接字来发送/接收这些二进制消息或使用某种形式的中间件。与套接字相比，使用中间件具有某些明显的优势。我关心的一些内容包括:通信模型 - 发布/订阅、请求/响应和故障转移。

另一方面，与中间件方法相比，使用套接字具有开销低的优势，并且会提供更好的性能。

人们还可以考虑使用 Protocol Buffers 提供的 RPC 库(谷歌 Protocol Buffer wiki 上的第三方插件)在客户端和服务器之间进行通信。尽管它从低级套接字中抽象出来，但它仍然不支持中间件功能。

目前，我的客户端是一个 Adob​​e Flex GUI 和两个服务器端进程(一个 java 和另一个 C++)。将来，客户端和服务器端可能会使用其他语言开发其他服务，例如 .NET

专家们对这些选择有何看法，以及根据经验，在不影响性能的情况下，哪些方法行之有效。开发人员还有其他选择吗？

谢谢十二月

Answer 1

除非是学习练习，否则您绝对必须使用一些中间件。有很多选择:AMQP、ZeroMQ、XMPP、Comet/Bayeux。

对于您的场景，您可能需要一些基于 Web 的东西，因此基于 HTTP 的 XMPP 可能是一个不错的选择。但是，我偏爱 Comet(尽管我发现 Bayeux 对我的需求来说太复杂了)。