这与我有关统一设置的问题有关（具有持久通道的端口统一 https://stackoverflow.com/questions/18445861/port-unification-with-persistent-channel)
我正在尝试发送一个两字节序列作为我的协议的所有流量的前缀；我这样做是为了当我更新以支持多个协议时，可以在统一处理程序中嗅探一些东西。
在客户端上，我在管道末端有一个简单的出站处理程序，它在 ByteBuf 前面加上两个协议标识字节，并在服务器管道前面有一个简单的入站处理程序，用于提取它们。我已经设法让它适用于小消息。
服务器队列中的后续处理程序是LengthFieldBasedFrameDecoder我用它来构建传入流量（protobuf 对象）。发生的情况似乎是客户端发送了一个大请求，比如 5M。我得到一系列通过服务器管道的 64k 缓冲区，其中最后一个超过了阈值LengthFieldBasedFrameDecoder正在等待，它提取帧并将其传递以进行处理 - 这是正确发生的。
至此，一切都破裂了。据我所知，来自客户端的最后一个 64k 缓冲区包含帧的其余数据、表示下一个请求开始的 2 字节序列，以及更多内容。我认为这些数据位于帧解码器中，它现在将使用两个协议魔术字节作为下一帧的长度，这是不正确的，并且事情从那里开始崩溃。
The DelimiterBasedFrameDecoder看起来它在这种情况下会起作用，因为两个字节序列将分解每个逻辑帧/请求，但在这种情况下这似乎有点矫枉过正。
在这种情况下是否有其他解码器可以工作，或者我应该坚持使用DelimiterBasedFrameDecoder?
如果您查看文档基于长度字段的帧解码器 http://netty.io/4.0/api/io/netty/handler/codec/LengthFieldBasedFrameDecoder.html有一个很好的例子说明了如何做你想做的事情。第四个示例在长度字段前面有一个固定宽度的标头，它配置 FrameDecoder 不去除任何标头信息。
EDIT
对于您的服务器，LengthFieldBasedFrameDecoder 应该首先出现，然后检查标头的处理程序可以删除标头和长度字段并相应地传递数据。
在客户端，您可以使用长度字段预置器 http://netty.io/4.0/api/io/netty/handler/codec/LengthFieldPrepender.html，然后添加一个额外的处理程序来添加您的标头数据。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
