0

我正在使用 netty 4 并利用 将ChannelPipeline协议状态管理之类的东西与编解码器分开（例如）。这非常有效 - 我喜欢管道的单线程（当你想要它时）性质。

我还想管理断开/重新连接。

但是 - 当“断开连接”时 - 我想保留本来会发送给断开连接的家伙的消息。我想这样做，同时仍然使用网络特性（即在持久性之前仍然使用我的处理程序在管道中进行编码等）。

显然，这个（逻辑）管道超过了一个通道的生命周期（当重新连接发生时，我将使用登录消息中发送的会话名称并将所有状态拉回新通道的管道）。

显然，我可以在 netty 之外完成这一切——但我仍然希望在断开连接时继续使用管道进行编码等。目前我能想到的只是使用某种“/dev/null/”风格（自定义）通道，它在我们断开连接时会丢弃所有内容，并在断开连接时适当重建管道（我们将在其中切换这个“假”死消息通道）并重新连接，以及EventExecutorGroup保持线程良好的自定义（即固定到“逻辑会话”状态 - 因此在通道之间移动）。这似乎有点“呃”:)

是否有任何现有的“模式”我没有看到记录在处理断开和重新连接之间的时间段同时保持状态和使用 netty 4 中的管道功能？

4

1 回答 1

0

听起来您正试图确保向客户“尽最大努力交付”。我处理类似的事情。

在上游，您需要一个带有队列和附加通道组的接收器。当客户端连接时，会创建这些接收器之一并将它们添加到通道组中。添加消息时，它们会同时添加到队列中并写入通道组。组中的每个连接都会收到这些消息。

在重新连接时，您（神奇地）将新客户端映射回接收器，并（神奇地）确定它在队列中的位置，并从队列中发送增量，并将他添加到组中。“神奇”的部分取决于你。

您确实需要担心此代码中的并发性，并且您必须担心接收器的手动垃圾收集。

我是 TTL 和 LRU 缓存的 Guava 的忠实粉丝，我在这种情况下使用过它们。

更新：

根据以下说明，您要求动态构建管道并重用处理程序。管道处理程序可以重用，所以这个序列图基本上应该做你想要的。

该图中未包含正在写入处理程序的外部进程。当 ctx 被分离并且连接在下游关闭时，您需要在有状态处理程序中处理对客户端的缓冲。我认为您可以尝试的确切机制。

希望这可以帮助。

于 2013-10-11T22:59:15.943 回答