在 Netty 的管道之外使用 DelimiterBasedFrameDecoder、StringEncoder 等答案

【问题标题】：Use DelimiterBasedFrameDecoder, StringEncoder, etc outside of pipeline in Netty在 Netty 的管道之外使用 DelimiterBasedFrameDecoder、StringEncoder 等
【发布时间】：2014-11-26 02:39:25
【问题描述】：

我正在使用 Netty 开发一个 TCP 服务器。我知道通常的用法是创建一个 ServerBootstrap 并将一个 Initializer 对象传递给 childHandler() 方法。在 Initializer 中有一个 initChannel 方法，我们使用一堆 addLast 命令设置管道，添加诸如 DelimiterBasedFrameDecoder、StringEncoder 等内容。这假设我们先验地知道我们将始终获得文本/字符串消息。

但是，我想实现类似于 Python Twisted 协议（如 LineReceiver）中存在的功能，我们可以在原始模式和线路模式之间来回切换。是的，一种方法是动态地从管道中删除和添加项目。但我想知道是否有任何充分的理由为什么我不能只使用使用基本 ChannelInitializer 的最小管道，其中处理程序只是 ChannelInboundHandlerAdapter 的扩展。这样，处理程序中的 channelRead 方法只处理原始字节（在 ByteBuf 中）。如果我想使用行模式，我是否可以在 channelRead 方法中使用 DelimiterBasedFrameDecoder、StringEncoder 等，即直接调用它们并在管道上下文之外使用它们？我有什么理由不应该这样做吗？

【问题讨论】：

标签： java netty

【解决方案1】：

一个简单的比较：

首先，您必须知道这些编解码器是如何工作的...
- 其中一些使用上下文来保留数据，只要没有足够的数据，来自传入消息的数据（如DelimiterBasedFrameDecoder）。
- 有些需要您编写一些额外的方法，因此按照您的方式编写并不妨碍您根据需要编写这些额外的方法。
- 有些人正在使用处理程序的上下文 (ChannelHandlerContext) 来存储一些内部信息（会话等），即使这种情况很少见。
树调用：因此您需要“手动”保持相同的行为，手动将正确的参数传递给它们（至少ChannelHandlerContext）。不确定你有什么收获。此外，流水线变得高效，例如在不需要时不会重新分配。
内存：由于您需要为每个通道创建一个（因为它们不可共享，如果它们是共享的，那么对于管道也是一样的），这与在管道中创建一个的成本相同。所以从记忆方面来说，不是更好。
初始化：手动添加/删除它到管道中/从管道中删除，而无需维护自己正确的调用顺序，我相信这比手动进行所有操作、分配、将其保存在私有通道处理程序属性中更容易。
行为：有些可能依赖 Netty 上下文 (ChannelHandlerContext) 才能正常工作（例如 CompatibleObjectEncoder、MarshallingDecoder）。如果这个ChannelHandlerContext 不是由 Netty 构建的，它会起作用吗？不知道...但是您需要确保编解码器充当您所知道的，当然。如果它被改变（因为外部 API 是相同的，但它实现它的方式改变了，所以你的情况下的行为），你必须知道它，否则你的代码可能会失败，你很快就会知道为什么......

因此，在简历中，我没有看到手动使用这些代码而不是根据需要将它们插入/删除到管道中的任何优势，但我确实看到如果内部实现发生变化而您没有注意到并且它破坏了您的风险“非标准”逻辑...

在那之后，没有什么是不可能的，所以你的选择;-) 但正如在其他 cmets 中所指出的，你可能想要编写自己的编解码器，从现有的编解码器中启发自己......

【讨论】：

【解决方案2】：

可以将所有编码器/解码器逻辑放入处理程序，但从架构角度来看这是个坏主意。

编写新的编解码器（编码器/解码器）会更好，甚至可以基于它们，您可以查看 StringEncoder 或 StringDecoder 内部，甚至可以查看 DelimiterBasedFrameDecoder 来了解如何做到这一点，事实上它们非常简单，或者在netty 网站上查看它们是如何实现 TimeEncoder 的。

之后，编解码器将有机会单独测试，处理程序和代码总体上会更加清晰。

【讨论】：