本文介绍了Netty-调用channel.disconnect()实际上关闭了通道的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在使用Netty 2.6.0.Final版.

I am using Netty version 2.6.0.Final.

如果我正确地理解了Netty文档,则在Channel上调用disconnect()应该可以让我调用connect()稍后再进行连接.但是,当我调用disconnect()时,我的SimpleChannelHandler子类的channelDisconnected()和channelClosed()都会被调用.

If I'm understanding the Netty documentation correctly, calling disconnect() on Channel should allow me to call connect() to connect again later. However, when I call disconnect(), both channelDisconnected() and channelClosed() of my SimpleChannelHandler subclass get called.

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

I opened this in debug mode and basically the order of events is:

  1. 我在自己的频道上调用disconnect()
  2. Channels.disconnect()被调用:

  1. I call disconnect() on my Channel
  2. Channels.disconnect() gets called:

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

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

  • Eventually, NioSocketPipelineSink.eventSunk() gets called, and the related part is:

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

  • 因此,由于value为null且状态为CONNECTED,通道将关闭(尽管根据此处 CONNECTED如果为null,则表示请求断开连接,不一定关闭.

    So since value is null and the state is CONNECTED, the channel gets closed (although according to here CONNECTED with null should indicate a request to disconnect, not necessarily close.

    那么我在这里想念什么吗?如果仅仅是导致通道关闭,那么connector()的意义何在?

    So am I missing something here? What's the point of disconnect() if it just results in the channel being closed?

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

    This isn't a huge problem, because if I need to I can just create a new Channel for my situation, but from initial inspection this seems like a Netty bug, unless I'm just misunderstanding how this is supposed to work or I'm doing something silly.

    推荐答案

    Netty的一个目的是提供一个统一的Channel抽象,该抽象对于面向连接的套接字(TCP)和不用于连接的套接字(UDP)大致相同. ,无论其基础实现是OIO,NIO还是AIO.由于存在许多差异,因此对于特定实现的某些部分,统一接口看起来会有些奇怪.

    One intention of Netty is to present a unified Channel abstraction that works more or less the same for connection oriented sockets (TCP) as for connection less sockets (UDP), regardless of the underlying implementation, OIO, NIO or AIO. Since there are quite a few differences, the unified interface will look a bit strange for some pieces of a particular implementation.

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

    The act of disconnecting a TCP socket implies closing it (at least from the Java API perspective). But disconnecting a UDP socket does not imply closing it, just removing the association between the local ip address/port and the remote ip address/port.

    因此,不,您没有做任何愚蠢的事情,但是我建议您对OPEN/CLOSE事件采取行动,除非您确实需要在其生存期内将UDP套接字连接"到不同的远程目标.

    So, no, you are not doing anything silly, but I would recommend acting upon OPEN/CLOSE events instead, unless you have a real need for "connecting" a UDP socket to different remote targets during its life time.

    在上一段中错过了一个重要的"not".

    missed an important "not" in the preceeding paragraph.

    这篇关于Netty-调用channel.disconnect()实际上关闭了通道的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

    10-12 05:25