在Netty的管道外使用DelimiterBasedFrameDecoder、StringEncoder等
我正在使用Netty开发一个TCP服务器。我知道通常的用法是创建一个ServerBootstrap并将一个初始化器对象传递给childHandler（）方法。在初始化器中有一个initChannel方法，在该方法中，我们使用一系列addLast命令设置管道，添加DelimiterBasedFrameDecoder、StringEncoder等内容。
但是，我希望实现一个类似于python扭曲协议（如LineReceiver）中的功能，我们可以在raw模式和line模式之间来回切换。是的，一种方法是动态地从管道中移除和添加项。但我想知道是否有什么好的理由不能使用一个使用基本ChannelInitializer的最小管道，其中处理程序只是ChannelInboundHandlerAdapter的扩展。这样，处理程序中的channelRead方法只处理原始字节（在ByteBuf中）。如果我想使用line模式，我是否可以在channelRead方法内部使用DelimiterBasedFrameDecoder、StringEncoder等，即直接调用它们并在管道上下文之外使用它们？我有什么理由不这样做吗？
共有1个答案
一个简单的对比：
- 首先，你必须知道这些编解码器是如何工作的...
- 其中一些使用一个上下文，只要数据不够，就会保留来自传入消息的数据（如
DelimiterBasedFrameDecoder)。 - 有些方法需要您编写一些额外的方法，所以按照您的方式编写并不妨碍您根据需要编写这些额外的方法。
- 有些人使用处理程序的上下文(
ChannelHandlerContext)来存储一些内部（session或类似的）。
因此，在简历中，我没有看到手动使用这些代码而不是根据需要将它们插入/删除到管道中有任何好处，但我确实看到了风险，如果内部实现在您没有注意到的情况下发生变化，并打破了您的“非标准”逻辑...
在那之后，没有什么是不可能的，所以你的选择；-）但是正如在其他评论中提到的，你可能想写你自己的编解码器，从现有的编解码器中激励自己...
- 其中一些使用一个上下文，只要数据不够，就会保留来自传入消息的数据（如
-
我的公司正在探索使用Netty框架实现消息路由器的可能性。它将要路由的消息来自许多不同的来源，并且都有自己的格式。在大多数情况下，消息都是XML格式的，其中包含一个包含正文长度的头。然而，我们有一个供应商谁的消息是不同的，不包含长度的身体。 这一个供应商的消息包含一个标题、正文和尾部。报头为1字节，是一个STX(0x02)，正文为可变长度，尾部为2字节，包含一个ETX(0x03)，后跟一个LRC。
-
在我的netty客户端中，我有一个初始管道，只有一个ChannelInoundHandlerAdapter。使用这个处理程序，我可以处理协议的握手。之后，我需要修改管道以供正常使用。这意味着我需要删除ChannelIn HandlerAdapter并添加LengthFieldPrepender/LengthFieldBasedFrameDecoder、Encoder/Decoder和一个处理程序。
-
传递参数 链接管道 我们可以将多个管道连接在一起，以便在一个表达式中使用多个管道。
-
目前，我在netty管道的末尾有一个处理程序，它处理几乎所有的请求逻辑。（使用jackson、身份验证、速率限制等从json解析对象。如果把这些放在执行器之后的管道中的各个阶段，是不是更好地使用管道结构？
-
我需要通过同一个连接向Rest服务器发送多个异步请求，并以FIFO顺序执行它们，我认为HTTP 1.1流水线非常适合这个。 我在Netty上发现了一些相关问题，但我在他们的用户指南上找不到太多，在他们的测试用例上也找不到任何东西。 Netty是否支持HTTP 1.1流水线？这将如何实现？ 一个例子将不胜感激。 相关问题 - 未解答- 问题： HTTP 1.1 流水线与 HTTP 2 多路复用
-
在 Netty 4.1 中，是否可以创建子通道/管道或嵌套通道/管道？ 例如，我有一个管道，其中安装了各种编解码器，用于协议/序列化。在管道结束时，我将一条消息传递给我的应用程序级逻辑。过度简化的示例： 然后，这个应用逻辑的句柄方法可以执行它想要的任何顺序逻辑。这清楚地分离了我的应用程序级别逻辑，但是，我想利用Netty的ChannelPipeline提供的“拦截过滤器模式的高级形式”。我想将管道