FixedHeaderPipelineFilter不能按照设置的Header匹配数据，若首次传输数据Header前有其他字节，不能匹配到完整的数据 #775

[lovemygirlkk99]

上demo

项目需求我主要想测试下这种效果比如客户端发送32 EF EF 30 31 32 EF EF 30 31 33 EF EF 30 ,协议头是EF EF ，后面三个字节是数据，解析出来的完整数据是两个EF EF 30 31 32、EF EF 30 31 33剩下来的EF EF 30数据进行缓存等待下次数据过来继续解析

那开头多的·32是怎么回事？是握手吗？什么时候会出现？这个应该包含在协议设计里面。

Originally posted by @kerryjiang in #775 这个32数据是我模拟的，有些时候设备推送的数据不是完全按照协议推送的情况

[kerryjiang]

不是完全按照协议推送？那按照的是什么？

[kerryjiang]

那怎么知道从哪里开始读？

[kerryjiang]

协议头是EF EF, 这个不完全符合FixedHeaderPipelineFilter，你可能需要基于FixedHeaderPipelineFilter自己实现前面头部查找的功能。

[StrangerLi]

他这种情况，在使用串口服务器时，可能会频繁复现。我之前遇到过类似情况，所以魔改过FixHeaderPipelineFilter。 复现条件如下：

3台设备：高频率自上报串口设备(如高精度电子秤等)、串口转TCP设备（串口服务器）、supersocket服务器

复现原理：

1. 串口设备是无法侦测TCP连接状态的，他是无脑向串口（RS232等）发送数据。
2. 串口服务器，只进行数据封包转发，在TCP连接建立后，即将串口数据转发到TCP Stream中
3. 在以下时间节点，比如TCP连接建立成功时，串口刚好发送了一半的报文至【串口服务器】，那么TCP服务器将会收到1个半包的报文。

另外还有一种其他的可能性：基于部分底层硬件开发人员的认知水平，他们将心跳报文视为必须发送至少1个子节，有些设备的实现就是发送一个FF，作为心跳

[StrangerLi]

为了应对这些情况，我的程序在应对工业物联网连接时，基本上使用的都是自定义PipelineFilter