昨天凌晨,突然接到云南移动哥们的电话,说他们正在进行的全网割接出现了问题,当时只有我们的产品遇到这样的问题,其他省的其他厂商的产品都已经顺利通过测试了。迷迷糊糊的我无奈的起床,开机,查找问题,这也让我体会到了这几天北方的夜晚的冷啊。

花了一段时间对底层的协议包进行了分析,发现我们产品发出去的消息包的那个域后面的确随机的分布着一些乱码字符。譬如我们的消息发送的目的地址是1069999333(Google的短信搜索),经过分析发现我们产品发出去的包中的这个域是这样的:3130 3639 3939 3933 3333 00f9 42 9678 0000 ….,一共是21个字节。粗略判断是我们协议栈发送功能实现的问题,但是又转念一想,虽说这个数据由瑕疵,但是数据接收方也是应该可以正确处理的啊,他们居然一反常态的校验出来其中的垃圾数据。之所以认为对方可是正常处理是因为对于这样的域,我们一般在业务层都会按字符串进行处理,大家都知道C语言中字符串是以''结尾的字符数组,那么对于上面例子中的那串数据,如果使用C中相应的字符串处理函数的话,是可以得到正确的信息:1069999333的,后面的垃圾数据会被最后一个3后面的''所隔开。

显然对方做了更加严格的校验了。也许当初实现我们的协议接口的同事太'单纯'了,没有想到对方'下手'会这么狠。开个玩笑罢了,其实归根结底还是我们自己实现的不完美导致的。早上上班来到部门,将事情和大家mail沟通了一下,居然另外一个项目组(其产品和我们属一类)发来邮件说这个问题他们早已经发现并修正了,但是忘记通知我们了。真是晕倒啊:),这也说明了及时的沟通与交流多么必要啊!

© 2008, bigwhite. 版权所有.

Related posts:

  1. C++咬文嚼字-'Hijack const'
  2. 开发人员之维护他人项目有感
  3. 推进项目改进,难!
  4. 又获Ubuntu 7.10光盘
  5. 万枚硬币送出人间温暖