通信協議文本化到底有多重要?老司機來告訴你
劉慈欣在其封神之作《三體》里描述過三體人的交流方式:倆人就這么站著不說話,四目相交,天雷引著地火,腦電波你來我往。沒有時延,不用等待,頃刻間便心與心相印,魂與魂深交,想來就十分美好。
本文引用地址:http://www.104case.com/article/202004/412589.htm相比之下,人類通過“語言”把隱晦的思考隱藏在幽微的心底,審時度勢,鼓舌如簧,說言不由衷的話,撒漫不經心的謊。
大劉在《三體》里,將此視為地球人類對三體人的一大優勢。上兵伐謀,兵不厭詐,在宇宙這座黑暗森林中,只有善于隱藏和偽裝,才能更好地生存。
是的,語言是一門隱藏真實的藝術。
其實,它不只在人類世界如此,在電子設備之間依然如斯。在電子設備之間,它有一個專業性的稱謂:通信協議。
一
電子工程師對“通信協議”這個詞匯耳熟能詳,如數家珍。平時掛在嘴邊的就有USB、RS232、CAN、LIN、ModBus、RS485、SPI、I2C、Zigbee、紅外、藍牙、WiFi......
“通信協議”也許是一個定義模糊的詞匯,因為,嚴格說起來,上面列舉的都是通信標準,或有線或無線,或廣域或局域,或遠程或短距,而且它們大多只是定義了物理層、鏈路層協議,當然有的還包含了傳輸層和會話層。
但是筆者今天想要跟大家探討的則是基于這些通信鏈路之上的應用層協議。
應用層協議和終端應用密切相關,就拿筆者比較熟悉的藍牙來說,針對車載免提有HFP協議,針對電話本傳輸有PBAP協議,針對耳機有A2DP、AVRCP協議......
除了這些針對特定場景具體應用制定了貼心協議的通信標準之外,有很多場合是需要工程師自己制定應用協議的,比如今天筆者要跟大家分享的測試工裝上位機和下位機之間的通信協議。
二
一把鑰匙一把鎖,一桿鋼筆一只筆帽,倚天劍得配個劍鞘,量產產品肯定需要測試工裝一套。
測試工裝咱就不多費筆墨了,總之就是上位機和下位機之間用串口或者USB,然后用類似于下面的老套通信協議互發報文:
報文頭(設為0x55+0xaa)+id(報文的ID)+data_len(數據長度)+data+checksum
大家伙對這種樣式的通信協議肯定是熟得不能再熟了,以至于可能熟視無睹,根本沒有意識到這里有哪些不對勁。
想想看,如果這種通信協議下的報文流出了問題,我們想搭眼看看哪里出了錯,是很難一看就看出個所以然的。
報文背后的信息就好像蒙了一層面紗,猶抱琵琶半遮面,千呼萬喚不出來。
我們需要把協議文檔翻出來,一條一條地比照才能知道這里的id到底對應的是哪一條具體的測試項,這里的數據到底表示什么意思。
不過好在,我們只要嚴格地按照報文格式封裝和解析這些報文,并保證報文的消費(解析)速度高過生產(接收)速度,干完這些dirty work之后我們就不需要關心它是不是那么朦朧難辨了。
畢竟,最終執行這些協議的都是計算機和電子設備,而這正是它們的強項。
所以,直到現在,我依然能夠想起幾年前采用這種方式做測試工裝時的那種心情:
九月里,平淡無聊,一切都好,只缺煩惱。
直到有一天,我和報文里的內容打起了交道。
三
本來,時光悠悠,歲月靜好,一切的一切都充滿了幸福的味道。
小張按照上文那種報文格式把某個測試項的請求發下來,我啟動具體的測試,把測試數據發給他,他按照測試項的具體功能邏輯,通過測試數據判斷測試是否通過。
時間滴滴答答,客戶端(上位機)和服務器(下位機)的請求和響應也沒有出過岔。
可是不知怎的,許是我改了改程序,又或者小張動了動代碼,那天下午出現了本該測試通過的測試項失敗的情況。
于是乎,秋高氣爽,艷陽高照,我和小張打起了嘴炮。
頂著沖冠的怒發,小張污我有的報文會漏發,我不留情面地說他的水平不到家,不知道用個buffer把接收的報文先緩存一下下。
為了證明報文不會漏發,我用工裝上多余的串口接上電腦上的串口助手,兩個串口的數據同時發,在串口助手的界面上把數據給他抓了一下。
然后,我倆對著電腦看了一會兒,各位看官呢,就一會兒,我們哥倆就懵圈啦!
那么多0x55 0xaa,誰知道后面那個id和數據表示的啥意思呀。面對這樣蒙著面紗的數據,誰看誰懵圈吧!
無法自證清白的我茫然地看著界面里的數據排得密密麻麻,一時間覺得無法招架。側過頭來,瞥見了小張無意識中張開的大嘴巴,‘真像是一個大傻瓜’。再轉過頭來,看了不大會兒數據又覺得眼花。
眼花是必然的,因為這里的數據報文本來就不具備可讀性嘛。
聚成了是一團火,反正它能很好地干活,但是散開了則是滿天星,對著你一閃一閃亮晶晶,讓你找起問題來火冒金星。
它又如浮萍在水,如淡云在天,只要勁風拂來,便是個萍亂云散的境地。
其實說到底,想自然地解讀這種不具備可讀性的通信協議是不是有些傻?
荒謬的感覺越來越盛,對通信協議的追問也越來越深入,然后我自然而言地提出了一個關鍵性的問題:通信協議可不可以具備可讀性?當然可以,藍牙的應用協議(profile)不就是可讀的嗎?怎么賦予它可讀性?文本化!
就這樣,一個呼吸之間,腦海里問題剛剛浮現,答案就出現在眼前,猶如天外飛仙。
我突然感到很佩服自己。
禪門大德開導座下弟子時,經常說一句:‘脫了衣服去!’通信協議文本化,何嘗不是脫掉了衣服,揭開了它的面紗?!
我把從心底瞬間涌上來的情緒,壓縮成一句話,最終把它一字一頓地說了出來:
萬物皆有靈,只需喚起它們的靈性。
話音甫落,小張的嘴巴張得更大了。
四
在兩個電子設備之間采用文本式進行通信,仿佛它們就脫離了無情種智,進入了有情眾生的世界。
向小張普及了這個思想之后,我旋即制定了一個可統一各個測試項的通信協議。
上位機發起測試請求,報文內容為“TestReq XXXrn”,其中的XXX代表具體的測試項,比如要測試信號強度,XXX=RSSI,比如要測試1號繼電器,XXX=RELAY1......
下位機返回測試結果,測試成功時報文內容為“TestResult XXX OKrn”,測試失敗時報文內容為“TestResult XXX ERRrn”,這里的XXX就是上述所謂測試項名稱。
具體解析時也很簡單,先通過換行符rn把一條獨立的報文提取出來,然后把報文頭“TestReq ”或者“TestResult ”查找出來,然后就定位到了XXX的位置,把它讀取出來即可。
封裝報文和解析報文也都變得無比地簡單,因為C語言有字符串函數支持上面這一系列操作!
這樣一來,在通信鏈路上傳輸的數據都是可讀的,而且報文通過換行符進行間隔,是不是漏發,是不是報文中間的數據發生了錯誤,都一目了然了。
后來,在文本化通信的幫助下,小張的問題也找到了。
原來,測試工裝上位機軟件設計時,對每個測試條目都加了超時限制,當它的計算機上打開很多軟件時,測試工裝上位機軟件的實時性就變差了,有的時候就自動觸發了超時,標記為測試失敗。
恩,小張這個設計思路當然有一定的問題,但是這不是本文要探究的主題:)
五
央視主持人大賽里有一期節目,里面有一個擂臺題目是“做新聞是內容重要還是形式重要”。雙方唇槍舌戰,鼓舌如簧,紛紛站在自己抽簽抽到的立場上引經據典,這邊說內容重要,那邊說形式重要。我當時看得那個著急啊,這些單純的讀書人啊,難道你們不知道,內容很重要,形式也很重要嘛!
就像本文討論的通信協議一樣,采用具有可讀性的文本形式既能很好地滿足雙方交互,又能明明白白地顯示給在一旁監控它運行的工程師,一箭雙雕,豈不美哉!
評論