@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.几秒的时候正好指令过来了，所以就连在一块了

长痘一般是由于皮肤油（比如我），我的办法是外用维 A 酸 + 洗面奶去油
所以结论就是保证面部不要有油，维 A 酸要用个几个月

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

确实，这外卖广告恶心得要死，举报举报不了，屏蔽也屏蔽不了，现在的 b 乎充斥着大量垃圾内容

大部分人是没有能力躺平，都是普通人，一个小小的打工人能走多高？

所以量力而行吧

@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);

}

```

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


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

#16 +1 这是你自己选择的结果，你可以选择 955 + 多走动 ，不加班剩下的时间还可以用来锻炼

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

@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]

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

@guancyxx4king 想回农村+1，可惜我也只能想想而已

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

能接收到，但不能主动发短信

推荐个冷门但我个人非常喜欢的策略游戏：《自然法则》高难度硬核 SLG

@manami +1 遇到过不少装 B 的面试官，通过贬低面试者来获得他那可怜的优越感

GFW 有点厉害，这种不知名小网站也能分分钟封掉

@czfy Bing 的搜索功能不太行，google 要翻墙太麻烦，这就是为何他有恃无恐，其实大家都不喜欢用百度，可惜国内没几个能打的

我挂了 VPN，但是 GOOGLE VOICE 为何提示所在地区不支持？