下雨声+呼吸声 ，最重要的是脑子里什么都别想

少有的上百条回复，看来这条帖子引起了很多人的共鸣

我甚至怀疑你在说我~~
零社交，除了八线老家的房子外，没车没房没女朋友，相亲了好几个也没成，每天得过且过，人生看不到希望

你不是一个人！

有时我甚至在想去乡下种田是不是都比这有意思（当然我知道种田很累）

楼主玩不玩游戏？可以一起。

@ptmicky 没搞懂，为了 199 块钱有什么好闹的，收了这么多彩礼又异地分居又是怎么回事？

信息太少了。

有条件就等到 9 月再去面试

@yuanmomo 前面的我能理解，但是一个月就同居这种骚操作是怎么做到的？

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

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

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

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

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

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