请教一个关于 netty 的问题， TCP 客户端在短时间内重连，旧的通道不关闭会一直触发未接收到心跳事件

[ReinerShir]

首先我添加了一个 netty 自带的心跳检测事件：

 channel.pipeline(). 
 //定义超时时间,参数分别为接收超时、发送超时、所有超时的时间
 addLast(new IdleStateHandler(60,0,0)).

即 1 分钟未收到数据包就断开连接

这是断开事件的处理：

/**
	 * TCP 事件触发管理
	 */
	@Override
	public void userEventTriggered(ChannelHandlerContext ctx, Object evt) throws Exception {
    if (evt instanceof IdleStateEvent) {//超时事件
    IdleStateEvent idleEvent = (IdleStateEvent) evt;
    //超时一段时间未接收到消息
    if (idleEvent.state() == IdleState.READER_IDLE) {//读
    //断开连接
    ctx.channel().close();
    }

}
super.userEventTriggered(ctx, evt);
}

现在问题来了，某个设备断电了，两秒后通电又重连了，然而在过了 60 秒后这个事件被触发了！因为老的连接通道一直未接收到数据，这时我会断开老的连接:ctx.channel().close(); ,我理想中的情况是老的连接就废弃了就让它断开嘛，新的连接通道继续使用就是，然而在我断开老的连接时新的连接也会断开。

这就导致了刚刚才通电恢复连接的设备又得重连，因此，想请教一下ctx.channel().close() 难道不是关闭当前的连接通道吗？为什么会将重新连接的通道也关闭了？

我也试过如果重连了就不关闭通道，但是不关闭的话该事件会一直触发，每 60 秒触发一次。

[dallaslu]

断开之前打印一下，即将断开的到底是哪一个 channel

[ReinerShir]

@dallaslu 打印过，断开的 channel 和新连接的 channel ID 是不一样的，但是奇怪的是我断开老 channel，新的连接也跟着一起断了

[3dwelcome]

是不是掉电后，系统两个 TCP 都用了一个 source port，打印一下呢。

比如你服务器发送 close()断开老通道，是向 192.168.1.5:4567 发送 FIN 消息。

结果新通道刚巧也是 192.168.1.5:4567，就被一起断开了。

[ReinerShir]

@3dwelcome 这个我也怀疑过，但是并不是这种情况，以下是我断电后打印的日志：

断电后重新连接：
重新连接 ，通道信息：[id: 0x15d2a4e1, L:/xxxx:8100 - R:/xxxx:27877]

重连后还是触发是未接收到心跳包：
将断开连接 ，连接通道：[id: 0x71bcb2a6, L:/xxxx:8100 - R:/xxxx:33776]

断开后再次重连：
重新连接，通道信息：[id: 0x6dc6bf85, L:/xxxx:8100 - R:/xxxx:50792]

可以看到每次重连源端口都是变化的

[4kingRAS]

你断开不要在 userEventTriggered 里写，直接 pipeline.addLast(new ReadTimeoutHandler(35)); 用自带的超时 handler

注意 pipeline 添加 handler 的顺序

[xinhochen]

可以抓下 TCP 包来看看新连接的断开是谁主动发起的，看下是 netty 还是设备

[ReinerShir]

@xinhochen 新连接的断开是应该 netty 发起的，通过日志看到执行断开老的 channel，但是新的连接也跟着一块断开了

[dallaslu]

来个可复现问题的代码吧

[xinhochen]

@ReinerShir 代码中有没有其它主动关闭 channel 的地方？如果没有，最好是抓 tcp 包，看设备日志，看程序日志。这三个放在一起分析，基本就能发现问题了。程序日志只能说明 channel 断开了，并不能说明是谁断开的。

[ReinerShir]

@xinhochen 设备因为条件限制没法看日志，通过程序的日志可以判断不是设备主动断开，因为我断开老 channel 后没有收到心跳包了，而且其它每个可能会断开 channel 的地方我都加了日志的，并没有触发


@dallaslu 核心代码是就上面那些了，复现的流程是，设备断电再打开 -> 两秒后设备重连 -> 60 秒后触发 netty 超时(IdleState.READER_IDLE)事件 -> 断开老的通道连接(ctx.channel().close()) -> 然后就没有心跳包了，新连接也断开了

[xinhochen]

@ReinerShir 设备如果用的 SIM 卡，要考虑运营商核心网的影响：设备断电后，netty 与运营商核心网的连接不会断开。建议把相关日志全部发上来看下，而不是截取部分，避免因为思维盲点遗漏了关键信息。

[xinhochen]

补充运营商核心网的相关信息：设备断电后，netty 与运营商核心网的连接不会"马上"断开

[ReinerShir]

@xinhochen 确实是用的 SIM 卡，用了个投机取巧的办法解决了

```java
@Override
public void userEventTriggered(ChannelHandlerContext ctx, Object evt) throws Exception {
if (evt instanceof IdleStateEvent) {//超时事件
IdleStateEvent idleEvent = (IdleStateEvent) evt;
//超时一段时间未接收到消息
if (idleEvent.state() == IdleState.READER_IDLE) {//读
String deviceNo = NettyChannelManager.getKey(ctx.channel());

if(!StringUtils.isEmpty(deviceNo)) {
Channel savedChannel = NettyChannelManager.getChannel(deviceNo);
Integer count = sessionRemoveMap.get(deviceNo);
//断开连接事件有可能在重连后触发，因此要判断是否已经重连了，如果未重连才真正的断开连接
if(count!=null||!savedChannel.isActive()) {
if(count>0) {
//移除标记
sessionRemoveMap.remove(deviceNo);
logger.warn("未接收到客户端消息，断开连接，设备号：{} ,{}",deviceNo,ctx.channel());
//断开连接并移除保存的状态
NettyChannelManager.removeAndClose(deviceNo);
ctx.close();
}else {
//如果已经重连，则本通道不要再触发无心跳包事件
//移除标记
sessionRemoveMap.remove(deviceNo);
return;
}
}else {
logger.info("断线标记：{} channel:{}",deviceNo,ctx.channel());
sessionRemoveMap.put(deviceNo, 1);
}
}else {
logger.warn("将直接断开连接,channel:{}",ctx.channel());
//直接断开
ctx.close();
}
}
}
super.userEventTriggered(ctx, evt);
}
```

第一次断线只是标记一下，第二次断线才真正断开，如果重连了，清除标记

```java
//如果已重连，将超时标记清除
if((action & 0x000000ff)==EventContract.EVENT_REPORT_AUTHENTICATION){
deviceId = NettyChannelManager.getKey(channel);
//如果之前确实断线过一次
if(sessionRemoveMap.remove(deviceId)!=null) {
//移除老通道
NettyChannelManager.removeChannel(ctx.channel());
}
sessionRemoveMap.put(deviceId,0);

}

```

[ReinerShir]

@dallaslu
@xinhochen
再请教一个问题，服务器发送指令到设备时有时候会和心跳包回复粘一块，比如心跳包用 channel.writeAndFlush(resp) 回复了 0x01 ,发送指令时同样用 channel.wrteAndFlush 返回 0x02，通过抓包发现偶尔会出现心跳包和指令连在一块的情况，即变成了 0x010x02

[xinhochen]

@ReinerShir 这种情况只能从消息定义上着手了，方案很多：分隔符（需要额外定义转义符，对应 netty 里的 DelimiterBasedFrameDecoder ）、长度字段(对应 netty 里的 LengthFieldBasedFrameDecoder)

[ReinerShir]

@xinhochen 我的错，没描述完整，我接收设备的消息是没问题的，服务端是做了分割的，代码如下：

@Override
protected void initChannel(SocketChannel channel) throws Exception {
channel.pipeline().
//定义超时时间,参数分别为接收超时、发送超时、所有超时的时间
addLast(new IdleStateHandler(60,0,0)).
//包尾以 EEFF 结束，使用 netty 自带的粘包处理器,false 参数表示不去掉包尾字符
addLast(new DelimiterBasedFrameDecoder(1024,false,Unpooled.copiedBuffer(TCPServerUtils.hexStr2bytes("EEFF")))).
//addLast(new LengthFieldBasedFrameDecoder(1024,2,1)).
//addLast(new LengthFieldPrepender(1)).
addLast(new CustomDecode()). //自定义解码器
addLast(new ServerEventHandlerAdapter(event)) //自定义处理器
;
}

和设备通信是用分割符的，服务端做了粘包和半包处理。

现在问题是出在设备端，有时候心跳回复和指令连在一起发过去了，我问了下设备那边的开发，他说是我发的不对，猜测可能是在心跳回复的那 0.几秒的时候正好指令过来了，所以就连在一块了

[xinhochen]

@ReinerShir 只有 Decoder，没有 Encoder 么？一般来说，发消息过去，也需要有分隔符之类的。要不然就会遇到你说的这种心跳和指令在一起的情况。

[ReinerShir]

@xinhochen 我查了下发现 netty 发现没有 DelimiterBasedFrameEncoder .唯一找到一个 MessageToByteEncoder 不明白怎么用，官方文档根本没提起该类。

我和设备之间通信是有自定义分割符的，例如返回信息给设备：
AABB0201EEFF ，其中 EEFF 就是包尾分割符。

现在的问题是我在代码中 writeAndFlush(AABB0201EEFF). 另一个线程 AABB0201EEFF(AABB0302EEFF),结果设备收到的是：AABB0201EEFFAABB0302EEFF ，这样子

[xinhochen]

@ReinerShir Encoder 就是自己继承 MessageToByteEncoder，然后实现 encode 方法。当然你那种把 AABB 和 EEFF 放在 writeAndFlush 里也是可以的，但是万一协议有变化，修改的工作量就大了，这就是为什么有 Encoder 存在的原因。
设备收到这种是非常正常的，需要设备那边对收到数据做处理，就和你在 netty 里对 EEFF 做处理是一样的。TCP 里的数据是流式的，一次收到的数据不全，或者收到多余的数据都是再正常不过的事了。

[ReinerShir]

@xinhochen 明白了，之所以来这里提问是因为设备开发那边说没办法做分割，所以才想能不能服务端这边确保每次发送数据都量独立一个包，谢谢啦。