为实时数据/移动设备设计网络协议

aur*_*amo 8 java tcp network-protocols

我面临以下两难困境:

设计一种新的网络协议,用于服务器(Java软件)与桌面和移动客户端之间.移动客户端包括J2ME,Android以及未来甚至iPhone.

数据流是一个实时,恒定的流,还有更多不常见的部分.客户端显示此数据的波形以及不需要立即更新的数据.客户端也应该通过身份验证.

如果可能的话,我想避免从头开始创建完全自定义的TCP协议实现.

这些天人们通常建议做REST风格的一切,我也非常喜欢.在这种情况下,我有点犹豫不决:如何在REST之上实现恒定的数据流?一个分块的HTTP响应?

我也在考虑非明文协议(我正在替换的当前协议是二进制协议).那些当前的协议有其相当严重的问题,所以它们确实应该被替换.

Google协议缓冲区看起来非常适合处理低级细节,但我不确定它是否可以在Android中使用.而且我很确定iPhone实现也会遇到问题.

还有BEEP,但我认为它已经死了,我想它是否被广泛使用过.

有任何想法吗?

Ami*_*imi 8

我认为在进入协议设计之前,您应该非常仔细地处理以下问题:

  • 如今,几乎除HTTP之外的所有协议都被防火墙过滤掉了.甚至许多内容类型和端口(除了80)也可以由服务提供商过滤,尤其是在移动数据服务中.因此,在选择使用或设计协议之前,请确保目标网络中没有防火墙问题.
  • 尺寸和速度很重要.尝试在传输消息大小和编码/解码(序列化/反序列化)速度中使用有效的协议.Google Protocol Buffers为此问题提供了可靠的解决方案.
  • 连接总是断开连接 由于NAT超时(默认为15分钟),协议超时(TCP为30分钟)和许多现有网络问题,您永远不能依赖连接长时间保持打开状态.因此,不要仅仅因为它保持连接打开而不喜欢另一个协议(它可能会尝试,但永远不会成功).发送心跳对于超时问题是一个很好的尝试,但网络断开连接仍然是不可避免的.
  • 吞吐量很重要.通过吞吐量,我的意思是在一段时间(例如1秒)内处理的消息的数量.使用在接收到消息后断开客户端的异步协议,确实有助于提高吞吐量.虽然不依赖于从服务器连接到客户端来推送结果,因为许多客户端都在NAT和防火墙后面,这避免了从外部直接连接.尝试保持连接打开或轮询服务器以获得结果.避免对话中的状态也是另一种有助于随着客户端数量的增长而扩展应用程序吞吐量的方法.
  • 现有WAN中没有实时.不要相信那些说他们已经实施了基于现有广域网协议的实时协议的人.您永远不能在非实时协议之上实现实时协议.你可以尽力而为网络祈祷.这意味着:不要停下来,尽力而为.
  • 非阻塞IO.NIO(非阻塞IO)现在是趋势,有效地用于网络编程.它支持大量连接,内存使用量更少,线程数量有限.Java 5对NIO有本机支持,非常原始.许多框架,如Apache MINANetty,都是基于Java NIO实现的,可以使非阻塞编程更容易,更健壮.我强烈推荐他们.


Mic*_*urr 2

您可能想看看RTP(实时传输协议),它可能没有直接用处(和/或可能有点过分),但它的设计会给您一些好的想法。而且您很可能能够使用它。