网络呼叫频道。disconnect（）实际上关闭了通道

Question

我使用的是 Netty 版本 2.6.0.最终版。

如果我正确理解了Netty文档，那么在Channel上调用disconnect（）将允许我稍后再次调用connect。然而，当我调用disconnect（）时，我的SimpleChannelHandler子类的channelDisconnected（）和channelClosed（）都会被调用。

我在调试模式下打开了它，基本上事件的顺序是：

>

我在我的频道上呼叫断开连接（）

通道断开连接（） 被调用：

public static ChannelFuture disconnect(Channel channel) {
  ChannelFuture future = future(channel);
  channel.getPipeline().sendDownstream(new DownstreamChannelStateEvent(
        channel, future, ChannelState.CONNECTED, null));
  return future;
}

最终，NioSocketPipelineSink。调用eventSunk（），相关部分为：

    case CONNECTED:
        if (value != null) {
            connect(channel, future, (SocketAddress) value);
        } else {
            channel.worker.close(channel, future);
        }
        break;

因此，由于值为null并且状态为CONNECTED，通道关闭(尽管根据这里的CONNECTED with null应该表示请求断开连接，而不一定是关闭。

我错过了什么吗？如果disconnect()只是导致通道关闭，那么它有什么意义呢？

这不是一个大问题，因为如果我需要的话，我可以为我的情况创建一个新的频道，但从最初的检查来看，这似乎是一个Netty bug，除非我只是误解了它应该如何工作，或者我在做一些愚蠢的事。

Answer 1

Netty的一个目的是提供一个统一的通道抽象，无论底层实现，OIO，NIO或AIO如何，它对于面向连接的套接字（TCP）和无连接套接字（UDP）的工作方式或多或少相同。由于存在很多差异，因此对于特定实现的某些部分，统一接口看起来有点奇怪。

断开TCP套接字的行为意味着关闭它（至少从JavaAPI的角度来看）。但是，断开UDP套接字并不意味着关闭它，只是删除本地ip地址/端口和远程ip地址/接口之间的关联。

因此，不，您没有做任何愚蠢的事情，但我建议您改为对OPEN/CLOSE事件进行操作，除非您确实需要在UDP套接字的生命周期内将其“连接”到不同的远程目标。

编辑：在前一段中遗漏了一个重要的“not”。