【问题标题】：How does upstream and downstream handlers work in Netty?上游和下游处理程序如何在 Netty 中工作？
【发布时间】：2012-03-11 13:40:56
【问题描述】：

我是Netty 的新手，并不真正了解其中的处理程序流程。我想知道的是Upstream 和Downstream 处理程序之间的区别。

为什么我们不能像在下游处理程序中那样拦截消息上游？
下游和上游的意思和正常术语一样吗？

【问题讨论】：

标签： java netty

【解决方案1】：

不同之处在于一个处理传入（上游）和另一个传出（下游）。我认为查看ChannelPipeline 的javadoc 后，事件/消息流变得更加清晰。

我还应该注意，上游事件只会由 IO-Thread 触发，因此如果您使用新的 ChannelUpstreamHandler per ChannelPipeline，则无需在其中同步字段访问。下游事件可以由任意线程触发，因此需要同步访问字段。

【讨论】：

感谢您的回复...但我不明白的是，在 Jboss Netty 站点中提供的 telnet 应用程序中，它使用上游处理程序打印从服务器发回的消息...但是他们为什么不使用下游处理程序......？您能否举一个下游处理程序的示例.....
就像我说的上游是用于传入的，实际上就是示例中的内容。下游事件的示例是需要将您写入的对象编码到 ChannelBuffer 的编码器。示例见github.com/netty/netty/blob/3.2/src/main/java/org/jboss/netty/…
很抱歉再次打扰您。您能否解释一下 IO 线程是什么意思？例如，在 Telnet 应用程序中，客户端上游处理程序被触发的方式是什么？我想这是我真的不明白的......
一旦收到缓冲区，它将触发一个事件，该事件将发送到 ChannelPipeline。 ChannelPipeline 将使用其 ChannelUpstreamHandler 实例来处理它。
它没有显示出来。我猜你认为它是从下到上的，但事实并非如此。当你仔细观察时，你会注意到上游是由传入的 Socket.read(..) 触发的。

【解决方案2】：

理论信息

我认为这些想法源自网络堆栈。 Netty 的 handler-pipeline 类比类似于 OSI 网络层堆栈。看看 OSI 网络层的样子：

将每个处理程序视为“一层”，将整个管道视为“一个网络堆栈”，将物理链接视为“IO源”，将用户视为“应用程序逻辑处理程序” .使用相同的管道（堆栈），我们需要做两个功能：

传输数据（向下发送数据，当“应用程序逻辑处理程序”想要通过“IO 源”做某事时）
接收数据（向上发送数据，当“IO 源”有一些事件，这可能是“应用程序逻辑处理程序”感兴趣的）。

所以本质上相同的管道必须做两件不同的事情（接收消息并发送回消息）。

实际例子

让我们考虑一个具体示例（具有身份验证和加密功能的服务器），由 3 个处理程序组成一个管道：

让我们从接收消息的角度来看看每个人的责任

加密处理程序 --> 在上述流程中，需要从“IO Source”接收UpstreamEvent，从“Application Handler”或“Auth Handler”接收DownstreamEvent。
Auth handler --> 只需要从“Encryption handler”接收UpstreamEvent。
应用程序处理程序 --> 只需要从“Auth Handler”接收UpstreamEvent。

因此，从逻辑上讲，每个处理程序都必须实现以下内容：

加密处理程序 --> ChannelUpstreamHandler 和 ChannelDownstreamHandler
身份验证处理程序 --> ChannelUpstreamHandler
应用程序处理程序 --> ChannelUpstreamHandler

所以如果你有一个ChannelPipeline，上面提到了 3 个处理程序，

对于传入消息：'IO 源'(0) 发起 UpstreamEvent，Netty 将把 UpstreamEvent 转发到 (1) 然后 (2) 然后可选地 (3)，因为所有 3 都实现了 ChannelUpstreamHandler。
当 'Application handler'(3) / 'Auth Handler'(2) 想要将状态消息发送回客户端时，它将通过write 调用（创建DownstreamEvent）启动。 Netty 会将DownstreamEvent 转发到(1) （这只是一个，在(3) 之前并实现了ChannelDownstreamHandler）。

因此，给定带有 handlers 的 pipeline，当一个 UpstreamEvent 被创建（通过 'IO 源'）时，Netty 将依次调用管道中的所有处理程序1 到 n，实现了ChannelUpstreamHandler（n 是处理程序的数量，在上面的示例中 n = 3）。并且当DownstreamEvent被创建（通过用户应用程序代码）时，Netty将依次调用管道中从n到1的所有处理程序，这些处理程序已经实现了ChannelDownstreamHandler .

由于一个类可以实现两个接口，一个处理程序可以是ChannelUpstreamHandler 和ChannelDownstreamHandler。请注意，所有UpstreamEvent 均由“IO 源”创建，所有DownstreamEvent 均由用户应用程序逻辑创建。

频道事件示例

UpstreamEvent 的示例：

收到消息
频道打开
频道关闭
“IO 源”引发的异常
写入由“IO 源”完成
频道已断开
...

DownstreamEvent 的示例：

给频道写消息
绑定到端口
连接到服务器地址
...

希望它能帮助您回答“为什么我们需要处理程序的两种行为（上游和下游）”、“Netty 如何通过Downstream 和Upstream 解决发送和接收”和“我们如何才能真正在实际应用中使用这些构造”。

你的答案到此结束，更多内容，你可以在下面继续。

关于上述处理程序

让我们看看上述每个处理程序在转发消息方面的责任：

应用程序处理程序 --> 需要将消息转发到前面的层（应该隐式或显式调用ctx.sendDownstream(e)）
Auth handler --> 需要将消息转发到前一层（认证失败）和下一层（认证成功）。（应隐式或显式调用 ctx.sendDownstream(e) 和 ctx.sendUpstream(e)）
加密处理程序 --> 需要将消息转发到上一层和下一层（应隐式或显式调用ctx.sendDownstream(e) 和ctx.sendUpstream(e)）。

【讨论】：