投票给出给定方案的最佳协议
我有一个设计决定。 我需要你的建议。
要求：
- 服务器和客户端。 客户端通常是手机。
- 通过互联网连接。
- 服务器和客户端希望相互通信。
- 在客户端和服务器之间交换文本，多媒体。
- 文本将是一些标准格式。 这是预先确定的。
- 实时要求
- 会话通常会持续5-15分钟。 在某些情况下，不到一分钟。 假设会话持续时间为5分钟。
- 该协议应遵守标准。
- 它必须是有效的。
选项1我为我的应用程序设计的二进制协议。
选项2将我的服务器实现为HTTPServlet。 客户端发送post请求，post消息中的查询和servlet在消息中发送响应。 但是，我认为对于实时交互，这不是一个好的选择，因为即使对于相同的客户端和会话，也会为每个post请求创建新线程。 请评论一下这个效率。
选项3使用普通的servlet。 将面临与上述相同的问题。
选项4使用SOAP
选项5使用REST
选项6使用Google Wave （我尚未阅读规范）
选项7建议其他一些协议
现在，我没有Web服务的经验，但如果它是选项，那么我不介意在其中投入时间。
基本上，我希望选项1的速度和效率采用标准的处理方式。
谢谢
听起来我觉得HTTP协议最适合你。 它的开销很低，已被广泛接受。 使用TCP [这是移动通信的要求]，它具有会话协商[连接良好而不是会话的实际状态]
使用不同的协议来共享video和音频，但使用http设置连接。
由于需要处理，使用SOAP / Web服务不是最佳的。 从个人经验来看，移动机器上的Web服务客户端更容易，但所需的处理过程非常流行，可能会在您的应用程序中造成瓶颈。 [移动机器不能很好地处理线程]
另外：由于您通过无线方式发送数据，因此您还必须考虑与非制导媒体相关的其他问题。
您的要求：
- 服务器和客户端。 客户端通常是手机。 ：是的
- 通过互联网连接。 ：是的，取决于您的设备网络的设置方式
- 服务器和客户端希望相互通信。 ：是的
- 在客户端和服务器之间交换文本，多媒体。 ：HTTP适用于文本和图像，但您需要切换到像UDP一样不可靠的video。
- 文本将是一些标准格式。 这是预先确定的。 ：是的
- 实时要求：这是不可能的，但可以尝试。
- 会话通常会持续5-15分钟。 在某些情况下，不到一分钟。 假设会话持续时间为5分钟：有标题可以保持会话打开
- 该协议应遵守标准。 ：RFC Something
- 它必须是有效的。 ：您需要做的唯一处理是逐行解析Key：data。
另外，我忘了提到SOAP / Webservices是XML over HTTP。
选项7为什么不选择XMPP ？
-
这是一个标准
-
它允许两个方向的消息。
-
您可以使用现有的XMPP基础架构（客户端可能使用他们的Google Talk帐户进行连接），也可以使用开源XMPP服务器轻松构建自己的XMPP基础架构
-
我也喜欢这样的事实，你基本上只编写客户端代码（因为服务器也是一个XMPP客户端） – 假设服务器和客户端都用相同的语言编写，你甚至可以使用完全相同的代码。
-
支持文件传输。
-
可以轻松扩展到您的需求
-
嗡嗡声（Google Wave）;）
人们可能争论的唯一问题是它的效率 – 或者一般的XML效率。 我不认为这是一个问题。
实时需求（如果按字面意思 ）削减了很多选择：HTTP协议不是实时的，因此它上面的任何东西（包括SOAP和REST）都有相同的弱点。 如果这是一个强烈的要求，你应该看看RTP协议或其他（至少）不做握手的事情。
使用选项1，使用ASN.1作为协议！ （有时称为二进制XML。）这会产生可由其他人理解的小型结构化消息。 这是一个受欢迎的标准，当您阅读此消息时，您刚刚使用它。 🙂
ASN.1是几种Internet协议的一部分。
转到选项1并使用Google协议缓冲区从协议定义中自动生成代码（即，它在保持高效的同时为您提供一致性/标准化）。
我建议选项3 ，不要担心线程问题。 如果您在servlet容器中托管它，容器几乎肯定会利用线程池来优化传入请求的处理并控制应用程序中的线程数。
此外，HTTP / 1.1支持管道和重用连接以用于后续请求。 这减轻了服务器设置和拆除连接的负担。
首先，如果您想将客户端放在手机上并拥有轻量级解决方案，请避免使用SOAP。 SOAP是浪费CPU和带宽的猪。 它也不是最简单的解决方案。
如果您打算在浏览器上实现客户端（使用javascript），基于JSON的解决方案是明显的路径，也很简单。 有关它的概念，请阅读这篇文章：
您可以在json.org找到更多资源
你可以使用JAX-RS作为美化的Servlet实现。 （我们中的许多人都说JAX-RS的JSR 311看起来就像Servlet规范从一开始就应该有的……这不是那么简单，但……）
关于“每个post一个post” – 这是一个非问题，因为您提到的所有技术在大多数应用服务器/ Servlet引擎上的行为方式相同 – 在给定时间处理的每个请求都将采用自己的线程。
（你不是在谈论Comet在这里 – 除非你有一个特殊的应用程序服务器，否则每个会话都会占用一个线程的tecnhology。）
选项1是一个很好的选择，如果你可以使它有效为您的目的。 但只要不需要选项1，我想选择选项2。 备选方案2实施得很好，并得到了很好的支持 如果使用HTTP 1.1，则不应每次都创建新线程
但是，如果您只需要传输文本，那么您可以使用选项1和一些文本压缩。 虽然解压缩文本有一点开销，但它应该太多了。 但它会减少移动设备的带宽使用。
Hessian是一个超过http的轻量级二进制协议。 有许多不同的Hessian实现，因此您可以为许多不同的客户端提供服务。
由于您关注效率，您可以在此处找到有关不同Java远程协议的一些指标： http ： //daniel.gredler.net/2008/01/07/java-remoting-protocol-benchmarks/