9

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

要求：

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

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

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

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

选项 4 使用SOAP

选项 5 使用REST

选项 6 使用Google Wave（我还没有阅读规范）

选项 7 建议一些其他协议

目前，我没有使用 Web 服务的经验，但如果可以选择，我不介意在这方面投入时间。

基本上，我希望选项 1 的速度和效率具有标准的做事方式。

谢谢

4

9 回答 9

13

在我看来，HTTP 协议会为您提供最好的服务。它的开销很低，已经被广泛接受。使用 TCP [这是移动通信的要求]，它具有会话协商 [连接明智而不是会话的实际状态]

使用不同的协议来共享视频和音频，但使用 http 设置连接。

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

另外：由于您通过无线发送数据，因此您还必须考虑处理非引导媒体的其他问题。

您的要求：

  • 一个服务器和一个客户端。客户端通常是手机。： 是的
  • 通过互联网连接。: 是的，取决于您的设备网络是如何设置的
  • 服务器和客户端想要互相交谈。： 是的
  • 客户端和服务器之间的文本、多媒体交换。: HTTP 可以很好地处理文本和图像，但是你需要切换到不可靠的东西，比如视频的 UDP。
  • 文本将是一些标准格式。这是预先决定的。： 是的
  • 实时要求：这是不可能的，但可以尝试。
  • 会话通常会持续 5-15 分钟。在某些情况下不到一分钟。假设会话持续时间为 5 分钟。：有标题可以保持会话打开
  • 该协议应遵守标准。: RFC 东西
  • 它必须是有效的。: 唯一需要做的处理就是逐行解析 Key: 数据。

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

于 2009-09-26T06:56:44.843 回答
12

选项 7为什么不选择XMPP？

  • 这是一个标准

  • 它允许双向消息。

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

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

  • 支持文件传输。

  • 可轻松扩展以满足您的需求

  • 嗡嗡声（Google Wave）；）

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

于 2009-10-09T11:44:50.160 回答
3

实时需求（如果从字面上理解的话）减少了很多选择：HTTP 协议不是实时的，因此它之上的任何东西（包括 SOAP 和 REST）都有相同的弱点。如果这是一个很强的要求，您应该查看RTP 协议或其他（至少）不进行握手的协议。

于 2009-10-08T23:10:52.797 回答
2

使用选项 1，使用ASN.1作为协议！（有时称为二进制 XML。）这会产生其他人可以理解的小型结构化消息。这是一个流行的标准，当您阅读此消息时，您只是使用了它。:-)

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

于 2009-09-25T16:04:50.277 回答
1

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

HTTP/1.1 还支持管道和重用连接以用于后续请求。这减轻了服务器建立和断开连接的负担。

于 2009-10-07T22:57:58.273 回答
1

选择选项 1 并使用 Google Protocol Buffers 从协议定义中自动生成您的代码（即，它为您提供一些一致性/标准化，同时仍然有效）。

于 2009-09-25T15:29:36.967 回答
1

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

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

于 2009-10-10T13:17:02.373 回答
1

如果您可以使其高效地实现您的目的，选项 1是一个不错的选择。但只要不需要选项 1，我想选择选项 2。 选项 2实施得很好，得到了很好的支持。如果您使用 HTTP 1.1，它不应该每次都创建新线程

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

于 2009-10-08T03:33:39.407 回答
1

对于初学者，如果您想将客户端放在手机上并有一个轻量级的解决方案，请避免使用 SOAP。SOAP 是浪费 CPU 和带宽的猪。这也不是最简单的解决方案。

如果您计划在浏览器上实现客户端（使用 javascript），那么基于 JSON 的解决方案是显而易见的路径，而且它也很简单。有关它会是什么样子的帮助，请阅读这篇文章：

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

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

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

（您在这里不是在谈论 Comet -除非您拥有特殊的应用程序服务器面包，否则该技术往往会在每个会话中占用一个线程。）

于 2009-10-08T03:12:37.467 回答