为给定方案投票选择最佳协议

Question

我有一个设计决定。我需要你的建议。

要求：

• 服务器和客户端。客户通常是手机。
• 通过互联网连接。
• 服务器和客户端希望彼此交谈。
• 在客户端和服务器之间交换文本，多媒体。
• 文字将是一些标准格式。这是预先确定的。
• 实时要求
• 会话通常持续5-15分钟。在某些情况下，不到一分钟。假设会话持续时间为5分钟。
• 协议应遵守标准。
• 一定很有效率。

选项1 我为我的应用程序设计的二进制协议。

选项2 将我的服务器实现为HTTPServlet。客户端发送post请求，post消息中的查询和servlet在消息中发送响应。 但是，我认为对于实时交互，这不是一个好的选择，因为即使对于同一个客户端和会话，也会为每个帖子请求创建一个新线程。请评论一下效率。

选项3 使用普通的servlet。 将面临与上述相同的问题。

选项4 使用SOAP

选项5 使用REST

选项6 使用Google Wave（我还没有阅读说明书）

选项7 建议一些其他协议

目前，我没有使用网络服务的经验，但如果是 选项，那么我不介意在其中投入时间。

基本上，我希望选项1的速度和效率采用标准的做法。

谢谢

Answer 1

对我来说，HTTP协议最适合您。它的开销很低，已被广泛接受。使用TCP [这是移动通信的要求]，它具有会话协商[连接良好而不是会话的实际状态]

使用其他协议分享视频和音频，但请使用http设置连接。

由于需要处理，使用SOAP / Web服务并不是最佳选择。从个人经验来看，移动机器上的Web服务客户端更容易，但所需的处理过程非常流行，可能会在您的应用程序中造成瓶颈。 [移动机器不能很好地处理线程]

此外：由于您通过无线方式发送数据，因此您还必须考虑与非制导媒体相关的其他问题。

您的要求：

• 服务器和客户端。客户端通常是手机。 ：是的
• 通过互联网连接。 ：是的，取决于设备网络的设置方式
• 服务器和客户端希望相互通信。 ：是的
• 在客户端和服务器之间交换文本，多媒体。 ：HTTP适用于文本和图像，但您需要切换到像UDP一样不可靠的视频。
• 文字将是一些标准格式。这是预先确定的。 ：是的
• 实时要求：这是不可能的，但可以尝试。
• 会话通常持续5-15分钟。在某些情况下，不到一分钟。假设会话持续时间为5分钟：有会话打开的标题
• 协议应符合标准。 ：RFC Something
• 一定很有效率。 ：您需要做的唯一处理是逐行解析Key：data。

另外，我忘了提到SOAP / Webservices是基于HTTP的XML。

Answer 2

选项7 为什么不选择 XMPP ？

• 这是一个标准

• 它允许双向发送消息。

• 您可以使用现有的XMPP基础架构（客户端可能会使用他们的Google Talk帐户进行连接），也可以使用开源XMPP服务器轻松构建自己的XMPP基础架构

• 我也喜欢这样的事实，你基本上只编写客户端代码（因为服务器也是一个XMPP客户端） - 假设服务器和客户端都是用同一种语言编写的，你甚至可以使用完全相同的代码。

• 支持文件传输。

• 可轻松扩展您的需求

• 嗡嗡声（Google Wave）;）

人们可能争论的唯一问题是它的效率 - 或者一般来说XML的效率。我不认为这是一个问题。

Answer 3

实时需求（如果采用literally）会削减很多选择：HTTP协议不是实时的，因此它上面的任何东西（包括SOAP和REST）都有同样的缺点。如果这是强烈要求，您应该查看RTP protocol或其他（至少）不进行握手的事情。

Answer 4

使用选项1，使用ASN.1作为协议！ （有时称为二进制XML。）这会产生可由其他人理解的小型结构化消息。这是一个受欢迎的标准，当您阅读此消息时，您刚刚使用过它。 ： - ）

ASN.1是多种Internet协议的一部分。

Answer 5

转到选项1并使用Google协议缓冲区从协议定义中自动生成代码（即，它在保持高效的同时为您提供一致性/标准化）。

Answer 6

我建议选项3 ，不要担心线程问题。如果您在servlet容器中托管它，容器几乎肯定会利用线程池来优化传入请求的处理并控制应用程序中的线程数。

此外，HTTP / 1.1支持管道和重用连接以用于后续请求。这减轻了服务器设置和拆除连接的负担。

Answer 7

首先，如果您想将客户端放在手机上并拥有轻便的解决方案，请避免使用SOAP。 SOAP是浪费CPU和带宽的猪。它也不是最简单的解决方案。

如果您计划在浏览器上实现客户端（使用javascript），基于JSON的解决方案是明显的路径，也很简单。有关它的概念，请阅读这篇文章：

• http://www.ibm.com/developerworks/web/library/wa-ajaxintro11.html

您可以在json.org找到更多资源

你可以使用JAX-RS作为美化的Servlet实现。 （我们中的许多人都说JAX-RS的JSR 311看起来就像Servlet规范从一开始就应该有的......这不是那么简单，但是......）

关于“每个帖子一个帖子” - 这是一个非问题，因为你提到的所有技术在大多数应用服务器/ Servlet引擎上的行为都是一样的 - 在给定时间处理的每个请求都将采用自己的线程。

（你不是在谈论Comet - 一个tecnhology，它往往采用一个每个会话的线程，除非你有一个特殊的应用服务器面包。）

Answer 8

选项1 是一个不错的选择，如果您可以为您的目的提高效率。但只要不需要选项1，我想选择选项2。 选项2 已得到很好的实施并得到了很好的支持。如果您使用HTTP 1.1

，则不应每次都创建新线程

但是，如果您只需要传输文字，那么您可以使用选项1 和一些文字压缩。虽然解压缩文本有一点开销，但它应该太多了。但它会减少移动设备的带宽使用。

Answer 9

Hessian是一个超过http的轻量级二进制协议。有许多不同的Hessian实现，因此您可以为许多不同的客户端提供服务。

由于您关注效率，您可以在此处找到有关不同Java远程协议的一些指标：http://daniel.gredler.net/2008/01/07/java-remoting-protocol-benchmarks/