协议缓冲区和实际传输选项 - 套接字或中间件
我正在开发一个客户端/服务器应用程序，我正在评估通信层的一些选项。
作为此通信框架的一部分，我正在考虑使用谷歌的协议缓冲区（PB）来表示传输数据，而不是重新发明我自己的二进制结构。
现在开始实际的传输，我想知道是否应该使用普通套接字来发送/接收这些二进制消息或使用某种形式的中间件。与套接字相比，使用中间件具有某些明显的优势。我关心的一些包括：通信模型 - 发布/订阅、请求/响应和故障转移。
另一方面，与中间件方法相比，使用套接字具有开销较低的优点，并且可以提供更好的性能。
人们还可以考虑使用协议缓冲区（Google 协议缓冲区维基上的第三方插件）提供的 RPC 库在客户端和服务器之间进行通信。虽然它从低层套接字中抽象出来，但它仍然不支持中间件功能。
目前，我的客户端是一个 Adobe Flex GUI 和两个服务器端进程（一个 java 和另一个 C++）。将来，客户端和服务器端也可能会使用其他语言（例如 .NET）开发其他服务。
专家对这些选择有何看法，以及根据经验，在不影响性能的情况下，哪种方法效果更好。开发人员还有其他选择吗？
谢谢 德斯
I am developing a client/server application for which I am evaluating a few options for the communications layer.
As part of this communication framework, I am contemplating using google's protocol buffer (PB) for representation of the transport data instead of re-inventing my own binary structure.
Now coming on to the actual transport, I am wondering if one should use plain sockets to send/receive these binary messages or use some form of middleware. Using a middleware has certain obvious advantages over sockets. A few that I care about include: communication models - publish/subscribe, request/response and fail over.
On the other hand, using sockets has the advantage of low overhead compared to the middleware approach and will deliver better performance.
One can also think of using the RPC libraries available with protocol buffers (third party add-ons on google's protocol buffer wiki) to communicate between the client and the server. Though it abstracts from the low level socket, it still does not support the middleware features.
At the moment, my client is an Adobe Flex GUI and two server side processes (One java and another C++). In the future, the client and server side can potentially have other services developed in other languages as well such as .NET
What do the experts feel about these choices and from experience what works well without compromising on performance. Are there other alternatives that developers go with?
Thanks
Dece
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
除非这是一个学习练习，否则您绝对必须使用一些中间件。有很多选择：AMQP、ZeroMQ、XMPP、Comet/Bayeux。
对于您的场景，您可能需要基于 Web 的内容，因此 XMPP over HTTP 可能是一个不错的选择。然而，我偏爱 Comet（尽管我发现 Bayeux 对于我的需求来说太复杂了）。
Unless it's a learning exercise, you absolutely, positively must use some middleware. There are lots of choices: AMQP, ZeroMQ, XMPP, Comet/Bayeux.
For your scenario, you probably want something web-based, so XMPP over HTTP may be a good option. However, I'm partial to Comet (though I have found Bayeux to be too complex for my needs).
哪个平台？
如果是 Windows，那么我有一个免费、简单、高性能、基于 IO 完成的可插拔服务器平台，称为 WASP，可以从 此处。
只需编写一两个 DLL 并将它们插入即可完成网络连接。
我目前没有基于协议缓冲区的插件示例，但它在我要做的事情列表中......
Which platform?
If Windows then I have a free, simple, high performance, IO completion based pluggable server platform called WASP which is available from here.
Simply write a DLL or two and plug them in and you're done with the networking.
I don't currently have a protocol buffers based plugin example but it's on my list of things to do...