java - 在 Netty 的管道外使用 DelimiterBasedFrameDecoder、StringEncoder 等

Question

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

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

Answer 1

一个简单的比较:

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

所以在简历中，我没有看到手动使用这些代码而不是根据需要将它们插入/删除到管道中有什么好处，但我确实看到如果内部实现发生变化而你没有注意到它会破坏你的风险“非标准”逻辑...

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