信息采集系统中,一场关于异构平台通信的风波

一.引子

前段时间用StriveEngine做 一个信息采集系统,服务器是Windows的,客户端是各种单片机,以及Unix等等平台。这些异构的平台,被我召集起来“加强对话, 扩大共识, 深化合作”。都说有人的地方就有江湖,讲真,机器世界也一样!这些异构的平台,平日里各自为政,井水不犯河水,倒也相安无事。如今群雄会盟,共商大计,如 我所料,势必会上演一波真正的血雨腥风!

就像新闻联播里常说的,“加强对话, 扩大共识, 深化合作”,首先得“加强对话”吧。

看着各位爷陆续到场,我稍稍清了清嗓子,不揣冒昧,说道:

“各路英雄好汉,这次把大家召集前来,是想让大家强强联手,搞一个大新闻!”

场下变得安静,各个聚精会神。于是我继续说道:

“到底是搞个什么呢?就是搞一个【信息采集系统】!”

场下开始窃窃私语。我接着说:

“大家有什么好的建议,有什么需要彼此沟通了解的,都请各抒己见,畅所欲言!”

掌声响起。

掌声落定。

代表们开始争相发言。

于是问题来了——他们都不讲普通话的好吗!——某型号单片机操一口湖南话,Windows服务器则操一口纽约腔——场面瞬时凌乱!更有一不可名状某终端, 恕我孤陋寡闻,您讲的是......是爪哇话吗?怎么还一股孜然味儿?更有两位爷看上去是一言不合,准备动手!我还在纳闷,这两位语言都不通,是怎么一言 不合的?!······场面逐渐失控,已容不得我多想!我大喝一声!30名侍卫持枪从侧门进场列阵台前,全场寂静!接着我一个响指,殿外快马加鞭,送上一 红绸遮盖的大匾,全场注视。我手气绸落,鎏金大匾上赫然写着金闪闪明晃晃的几个大字:

二.面向字节流的TCP通信

这一切还得从TCP通信说起。

TCP大家都不陌生,是网络协议栈中最重要的协议之一。StriveEngine通信引擎既支持TCP也支持UDP,我们根据业务场景的需要选择的是TCP。TCP是面向字节流的。

      

三.面向字节流通信所引发的问题

正是因为TCP通信面向字节流,同时也引发也一系列相关问题需要我们去着手解决。

1.粘包

其中首当其冲的,也是大家最熟悉的就是粘包问题。

字节流就跟水流一样,当两个消息一起读取时,你无法分别出二者的边界。

2.字节序·大小端方式

TCP是面向字节流的,这个字节流本质上来说就是内存片段。那么问题来了,发送主机与接收主机的存储方式可能不一样,也就是主机字节序不一致。

打个简单的比方吧,以前中国的书都是从右往左读写的,而现在都是从左往右读写的。假使现代人按照现在的习惯去读过去的书,就会因为【主机字节序】不一致而出现问题。

就如同读写可以从左往右,也可以从右往左,马路可以规定靠左侧行驶也可以规定靠右侧行驶——存储方式也有两种——【大端方式】和【小端方式】。

《格列佛游记》中记载小人国中形成了两派政治势力,一派主张吃鸡蛋时要从大端开始剥,另一方则主张要从小端开始剥,一言不合就兵连祸结,烽火频年。

计算机科学借用了这个典故来命名两种存储方式:

遗憾的是大小端方式的分歧在计算机世界里也未能达成一致,因此就造成了异构平台通信过程中主机字节序列不一致的问题。

四.如何解决?

首先要明确一点,这些问题都是【应用层】的问题!因为传输层,或者整个底层通信所肩负的职责就是【通信】,其他的事情不该管也管不了!特别是TCP通 信,我们知道TCP是可靠传输——发送方发的啥我保证原封不动的给你送到,至于你收到一看,哎呀,包粘在一起了我怎么分得清楚?哎呀,这发过来的数据我解 析出来怎么是乱码?——这都不关TCP通信的事!这是你程序员要做的消息处理的工作,消息传输TCP帮你干了,而且TCP是出了名的"铁齿金不换,诚实可 靠小郎君",已经仁至义尽,处理消息、解析消息的工作就要靠身为程序员的你来大显身手了!

1.粘包问题

 StriveEngine通信引擎提供了两种解决方案:

文本协议模式

   二进制协议模式

其中更为根本的是二进制协议模式。二进制协议通过给消息加上报头,从而为消息定界。

复制代码
    // 摘要:
    //     二进制协议助手接口。
    public interface IStreamContractHelper
    {
        // 摘要:
        //     消息头的长度。
        int MessageHeaderLength { get; }

        // 摘要:
        //     从消息头中解析出消息体的长度(注意,不是整个消息的长度,而是不包含消息头的Body的长度)。
        //
        // 参数:
        //   head:
        //     完整的消息头,长度固定为MessageHeaderLength
        int ParseMessageBodyLength(byte[] head);
    }
复制代码

这个接口是需自己来实现的。接口只要求了两件事:1.消息头长度是多少?2.如何从消息头中取出消息体长度,从而间接取出消息体。至于具体的协议如何设计,这个并没有一定之规。

2.字节序问题

字节序的问题就更简单了。已经说过,通信负责把数据原封不动的从端到端进行传递,现在数据交给我了,我发现字节序不一致。不一致怎么办?转换呗!

 void tcpPassiveEngine_MessageReceived(IPEndPoint serverIPE, byte[] bMsg)
 {
     ······
 }

这个字节数组就是收到的数据,该怎么转换在方法体里面做就是了。而且这些转换都早已被封装成API,因此并没有什么难度,本文就不赘述了 。

———————————————附项目源码下载地址———————————————————

五.言归正传

为川者决之使导 ,为民者宣之使言。从那以后,那些机器之间的交流日益加深,有些还建立了深厚的友谊。我时常训导他们,你们虽然是机器,但是也要有人味,要放下那些所谓的 成见,求同存异。大家的思维方式、文化背景、受教育程度也许都不尽相同,但是只要大家以一颗开放的心去彼此了解,彼此沟通,交换立场,推己及人,就能开展 合作,就能超拔出个人的小生命,而进入到一个更大的生命中。要完成一个数据采集系统,你们其中的任何一个都不能单独胜任,只有靠大家群策群力。而要做到群 策群力,就要兼收并蓄,不能各执一端。比如你是小端方式存储,就非要排斥搞大端方式的,视他们为异端,恨不得消灭殆尽,这是最危险的!一定要相互理解相互 包容,要尝试去了解对方,学习对方的话语。还有些高级些的系统瞧不起单片机,觉得跟他们没有共同语言,这也是不对的。尺有所长寸有所短,要优势互补才对。 管子讲:“和合故能习,习故能偕,偕习以悉,莫之能伤也”,只有和合偕习,才能真正强大!

后来陆续有机器私信给我,说学到了很多做人的道理。为此我倍感欣慰。

http://www.cnblogs.com/aoyeyuyan/p/5644160.html

  1. da shang
    donate-alipay
               donate-weixin weixinpay

发表评论↓↓