java - 使用 Netty 收到的消息是否可能出现故障或受到限制？

Question

嗯，我使用netty框架java，通过concox设备协议(protocol)处理消息，我的应用程序收到的消息似乎与预期的不同。

收到的消息就像

EF BF BD EF BF BD EF BF BD 0D 0A 78 78 1F 12 13 0A 1C 0F 12 1D EF BF BD

预期应该是

78 78 23 12 10 03 1D 0F 17 12 C7 02 6B 6E 38 0C 39 71 00 0B 15 0E 01 CC 00 24 95 00 13 93 00 02 3D 7C 01 09 27 35 0D 0A

78 78 是起始位 0D 0A是停止位

这可能是什么？我们将此应用程序库用于许多协议(protocol)并且它们可以工作 支持人员说这可能是缓冲区连接的问题，但我不知道怎么可能。

我可以处理起始位和停止位位置错误的问题。 但预期的信息仍然要大得多。

文档链接是http://www.iconcox.in/images/tr-06-protocol.pdf

我们的代码

public abstract class ExtendedObjectDecoder implements ChannelUpstreamHandler {

    @SuppressWarnings("rawtypes")
    public void handleUpstream(
            ChannelHandlerContext ctx, ChannelEvent evt) throws Exception {
        if (!(evt instanceof MessageEvent)) {
            ctx.sendUpstream(evt);
            return;
        }

        MessageEvent e = (MessageEvent) evt;
        Object originalMessage = e.getMessage();

        System.out.println((String) originalMessage);
    }
}

管线

@Override
    public void initTrackerServers(List<TrackerServer> serverList) {
        serverList.add(new TrackerServer(new ServerBootstrap()) {
            @Override
            protected void addSpecificHandlers(ChannelPipeline pipeline) {
                pipeline.addLast("frameDecoder", new CharacterDelimiterFrameDecoder(4096, "$", "\0"));
                pipeline.addLast("stringEncoder", new StringEncoder());
                pipeline.addLast("stringDecoder", new StringDecoder());
                pipeline.addLast("objectDecoder", new EquipProtocolDecoder(EquipProtocol.this));
            }
        });
        serverList.add(new TrackerServer(new ConnectionlessBootstrap()) {
            @Override
            protected void addSpecificHandlers(ChannelPipeline pipeline) {
                pipeline.addLast("stringEncoder", new StringEncoder());
                pipeline.addLast("stringDecoder", new StringDecoder());
                pipeline.addLast("objectDecoder", new EquipProtocolDecoder(EquipProtocol.this));
            }
        });
    }

Answer 1

Netty 被设计为实际协议(protocol)之上的一个简化层，因此继承了许多语义。

一个重要的语义是 TCP 是一种基于流的协议(protocol)，这意味着当您读取任何数据时，您会按顺序获取所有数据，但数据可能分布在多个数据包中，或者所有数据可能都在同一个数据包中。

您的代码没有正确处理这个问题，这导致了您的问题。

您的情况发生的是远程发送 2 个“协议(protocol)特定数据包”，读取后，这些数据包与“tcp 数据包”混合在一起

• 之前:Aaaaa Bbbbb Cccc Ddddd
• 之后:Aaa aaaBbbbCccccDdddd

您需要一些东西来再次重建原始消息。

目前，您的管道存在一个 StringDecoder，后面是您的业务处理程序。不幸的是，StringDecoder 不适合处理原始传入数据的任务，并且可以actually cause corruption处理原始传入数据时。

幸运的是，“tr-06”在每个数据包中都有一个长度字段。 (检测起始位和停止位的存在是不可靠的，因为它们也可能位于数据包内)我们可以使用此长度字段将“字节流”再次解码为“数据包”。让我们从文档中收集一些信息协议(protocol):

iv.Data Packet Format

The communication is transferred asynchronously in bytes.The total length of packets is (10+N) Bytes

...

4.2.Packet Length

Length = Protocol Number + Information Content + Information Serial Number + Error Check, totally (5+N)Bytes, because the Information Content is a variable length field.

我们最终希望使用预构建解决方案来“构建”字节，因此让我们阅读 DelimiterBasedFrameDecoder 的文档。我们可以看到“5 字节 header 末尾有 3 字节长度字段，不剥离 header ”的示例与我们的需要非常匹配，但并不完全如此。让我们根据这些示例计算正确的数据:

我们在协议(protocol)示例中看到长度字段位于起始位之后，并且起始位为2个字节长，因此偏移量变为2

lengthFieldOffset   = 2

根据文档，数据包长度字段为1，意味着它支持长度最大为255字节的数据包

lengthFieldLength   = 1

这是一个很难计算的问题，Netty 假设数据包长度是数据包中包含长度字段之后的所有字节，因此让我们从 Netties 角度计算它，看看它是如何排列的。

Netty:1 + N + 2 + 2 + 2 协议(protocol):1 N + 2 + 2

lengthAdjustment    = 2

我们需要将长度字段调整2

我们不想删除任何字节(如果您对起始位和停止位不感兴趣，您可能需要稍后启用此功能)

initialBytesToStrip = 0

让我们把它们放在一起:

        @Override
        protected void addSpecificHandlers(ChannelPipeline pipeline) {
            pipeline.addLast("frameDecoder", new LengthFieldBasedFrameDecoder(255, 2, 1, 2, 0));
            pipeline.addLast("stringEncoder", new StringEncoder());
            pipeline.addLast("stringDecoder", new StringDecoder());
            pipeline.addLast("objectDecoder", new EquipProtocolDecoder(EquipProtocol.this));
        }