【问题标题】:Efficient way to extract protocol data units from tcp byte stream从 tcp 字节流中提取协议数据单元的有效方法
【发布时间】:2013-07-10 13:50:53
【问题描述】:

我有两个依赖于基于字节的面向连接协议的java项目(简单的多人游戏) 用于交流。

在这两种情况下,我都不满意通信的实现,因为我无法提出一种智能的、非冗长和面向对象的编写方式,尤其是解析字节。


对于写作我有类似的东西

ProtocolDataUnitX pdux = new ProtocolDataUnitX("MyName", 2013);
int[] bytes = pdux.getBytes();
out.write(bytes); // surrounded with try/catch etc.

这在某种程度上是可以接受的,因为我有一个带有一些字节转换便利方法的AbstractPDU 类。但我必须定义getBytes() 方法 对于每个协议数据单元 (pdu)。 我解析传入字节流的方法缺乏更多创新。

private InputStream in;

...

@Override
public void run() {

    int c;
    while ((c = in.read()) != -1)) {
                if (c == 0x01) {
                    // 0x01 means we have pdu #1 and can continue reading
                    // since we know what is coming.
                    // after we have all bytes and know the pdu
                    // we can determine the paramters. I.e., every pdu has a
                    // reverse constructor: bytes -> pdu
                }

问题

您如何处理这些情况?这里有哪些最佳做法?有些协议对总长度字段进行了编码,有些则没有。一些协议数据单元具有可变长度。 这里有合理的方法吗?也许某种模式定义?我不想再为此编写丑陋和令人困惑的代码。

【问题讨论】:

  • 您是否考虑过使用 Google protobufs (code.google.com/p/protobuf) 并让他们为您完成所有繁重的工作?
  • 以前从未听说过。谢谢,听起来很有趣。这里有一个指向 Java 源代码的链接 code.google.com/p/protobuf/source/browse/trunk/java/src/main/…
  • 好的,我会回答的。
  • 好的,但我现在不能接受,因为我仍在等待答案,这些答案能给我提供更广泛的设计原则和解决我的问题的方法。即使我对谷歌资源进行逆向工程,我也只有一种方法。
  • 好吧,我已经尽力了。请记住,像您这样的开放式问题通常被认为不适合 SO。见stackoverflow.com/help/dont-ask

标签: java parsing tcp protocols


【解决方案1】:

总结:最佳实践是使用现有的、成熟的协议编译器。 Google protobufs 是一个受欢迎的选择。


多年来,已经开发了许多协议定义系统。其中大多数包括编译器,这些编译器采用协议描述并生成客户端和服务器代码,通常使用多种语言。这种编译器的存在对于不限于单个客户端(或服务器)实现的项目非常有帮助,因为它允许其他团队使用标准 PDU 定义轻松创建自己的客户端或服务器。此外,正如您所观察到的,制作一个干净的面向对象的接口并非易事,即使是在 Java 这样的语言中,它具有您需要的大部分功能。

PDU 是否应该具有明确的长度或自定界(例如,带有结束指示符)的问题很有趣。显式长度有很多优点:一方面,不需要完整的解析器来接受 PDU,这可以更好地将反序列化与传输隔离。如果传输由 PDU 流组成,则显式长度字段使错误恢复更简单,并允许将 PDU 提前分派给处理程序。显式长度字段还可以更轻松地将 PDU 嵌入到另一个 PDU 中,这通常很有用,尤其是在 PDU 的某些部分必须加密时。

另一方面,显式长度字段要求在传输之前将整个 PDU 组装在内存中,这对于大型 PDU 来说很尴尬,并且不可能使用单个 PDU 进行流式传输。如果长度字段本身是可变长度的,这几乎总是必要的,那么创建 PDU 组件就变得很尴尬,除非一开始就知道最终长度。 (解决这个问题的一种方法是创建序列化字符串backwards,但这也很尴尬,并且不适用于流式传输。)

总的来说,虽然有些系统允许“分块”,但平衡一直有利于显式长度字段。一种简单的分块形式是定义最大块大小,并将具有最大大小的连续块与大小小于最大值的第一个后续块连接起来。 (重要的是能够指定长度为 0 的块,以防 PDU 是最大大小的偶数倍。)这是一个合理的折衷方案;它允许流式传输(有一些工作);但它需要更多的工程工作,并且会产生很多需要测试和调试的极端情况。

设计 PDU 格式的一个重要准则是每个选项都可能导致信息泄漏。在可能的范围内,尽量使任何给定的内部对象只有一个可能的序列化。另外,请记住,冗余是有代价的:只要有重复,就意味着要进行有效性测试。将测试保持在最低限度是提高效率的关键,尤其是在反序列化方面。跳过有效性测试会招致安全攻击。

在我看来,制作一个 ad hoc 协议解析器通常不是一个好主意。一方面,工作量很大。另一方面,有很多微妙的问题,最好使用处理过这些问题的系统。

虽然我个人是 ASN.1 的拥护者,它在电信行业中得到了广泛的应用,但它并不是一项容易融入小型项目的技术。学习曲线非常陡峭,而且开源工具并不多。

目前,最流行的选项可能是Google protobufs,它可用于 C++、Java 和 Python(以及通过贡献插件提供的许多其他语言)。它简单、易于使用且开源。

【讨论】:

  • 很好的答案!还 +1 用于提及关键字“协议编译器”和 ASN.1。 ...不过,我仍然对这两个项目背后的设计原则感兴趣 :) 谢谢!
猜你喜欢
  • 1970-01-01
  • 2010-10-24
  • 1970-01-01
  • 2011-08-27
  • 1970-01-01
  • 2013-07-25
  • 1970-01-01
  • 1970-01-01
  • 2018-12-24
相关资源
最近更新 更多