JAVA关于TCP协议自定义解析数据出错,私有协议解析常见问题

文章讨论了物联网项目中与单片机通讯时使用自定义协议的常见问题,包括TCP层的数据解析、协议解析的正确性和完整性,以及不同语言间的数据表示差异。作者强调了协议设计的明确性,例如使用数据长度标识和避免TCP的粘包问题,并推荐了一个名为Magic-byte的Java工具,用于简化对象的序列化和反序列化过程。
摘要由CSDN通过智能技术生成

现在的物联网项目中,很多项目都会涉及到和单片机通讯。

所以大多数项目会使用自定义协议来实现。这里总结一些常见的坑,减少大家踩坑。

第一点,大家一定要明白在TCP层发送的都是字节数据,而私有协议本身就是如何解析这些字节数据,这一点非常重要!

  1. 协议解析数据错误
    对于私有协议来说,第一步一定要和设备端开发确认技术选型,通讯使用HTTP?还是TCP?,如果使用TCP,发送数据的时候每种数据类型发送格式是什么?比如整数是按照字节直接发送,还是直接将整数格式化为字符串再发送。这些细节都应该在开发前约定好。不然就可能出现,设备端发送的是字符串,云端直接使用ASCII码的字节解析为整数。这样就牛头不对马嘴了。永远对应不上了。
    详细的例子:
    比如,设备端使用TCP协议,所有数据使用内存储存结构进行发送,
    比如设备端发送整数 100;那么只需要一个字节(每个无符号字节范围0-255)即发送数据为:[0x64];
    如果使用字符串发送,则需要3个字节。因为需要将整数100转译为ascii码的[0x31, 0x30, 0x30]。
    上面例子中,解析同一个整数100,字节发送内存结构数据只需要一个字节,而发送ascii码需要三个字节。所以在开发中更推荐使用第1种方式。

  2. 协议解析数据不全
    数据不全这一点在TCP协议中很容易出现,由于TCP协议的分片问题,这里就需要注意协议中的粘包问题。
    也就是协议中应该存在一个明确的标识符或者数据长度来表明当前数据包开始和结束,否则在在解析时就总会出现读包错误。当然UDP就没有此问题,但是一般是不推荐使用UDP协议的。

  3. 协议解析总是不对
    这一点一般是在对接时候,沟通细节没有做到位。比如一个字节数组,C发送过来的可能时无符号位的,而JAVA在解析时却是有符号位。这样解析是肯定不正确的。再比如,C发送过来字符串是GBK编码,而java使用UTF8解码。这样也是牛头不对马嘴的,所以遇到此类问题,一定要多和C开发进行沟通。

最后,鉴于物联网肯定是以后的趋势,而我在这块开发也比较多。于是就封装了一套java对象自定义序列化的工具:magic-byte。可以快速的将java对象序列化为字节或者将字节进行反序列化。特别适用于与第三方语言私有协议的开发。
框架经过了我司的线上验证,希望可以帮助到大家。

Magic-byteGITHUB链接

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值