Netty - 调用channel.disconnect()实际上关闭了通道

Question

我使用的是Netty版本2.6.0.Final.

如果我正确理解Netty文档,在Channel上调用disconnect()应该允许我稍后再调用connect()来连接.但是,当我调用disconnect()时,我的SimpleChannelHandler子类的channelDisconnected()和channelClosed()都被调用.

我在调试模式下打开它,基本上事件的顺序是:

1. 我在我的频道上调用disconnect()

2. 调用Channels.disconnect():

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

3. 最终,NioSocketPipelineSink.eventSunk()被调用,相关部分是:

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

因此,由于value为null且状态为CONNECTED,因此通道将关闭(尽管根据此处 CONNECTED with null应指示断开连接的请求,不一定关闭.

我在这里错过了一些东西吗？如果它只是导致通道被关闭,那么disconnect()的重点是什么？

这不是一个大问题,因为如果我需要,我可以为我的情况创建一个新的频道,但从最初的检查看起来这似乎是一个Netty错误,除非我只是误解了它应该如何工作或我'做一些傻事.

Answer 1

Netty的一个目的是提供一个统一的Channel抽象,它对于面向连接的套接字(TCP)和连接少套接字(UDP)大致相同,无论底层实现,OIO,NIO还是AIO.由于存在相当多的差异,统一接口对于特定实现的某些部分看起来有点奇怪.

断开TCP套接字的行为意味着关闭它(至少从Java API的角度来看).但断开UDP套接字并不意味着关闭它,只是删除本地IP地址/端口和远程IP地址/端口之间的关联.

所以,不,你没有做任何愚蠢的事情,但我会建议代替OPEN/CLOSE事件,除非你真的需要在其生命周期内将UDP套接字"连接"到不同的远程目标.

编辑:错过了前一段中的重要"不".