關于制定通信協議

關于制定通信協議

制定一個通信協議：
制定協議一定要考慮，可靠性ecc，完備性，可擴展性，
除了考慮帶寬而節省字節數的pack緊湊外，還有考慮不對齊問題引發的cpu處理頭元數據的低效問題

分片和重組問題，重傳問題。

安全性問題，加密，防偽，防***, 認證防偽

如何識別包頭的分幀問題，引入magic頭和magic尾。即同步問題, 收發端同步

1）OBD：
數據都是ascii碼，\r\n作為一幀數據的結束，所以，如果有一幀串口數據接收錯誤，長度錯誤例如本應10字節，結果收到5字節，那么由于\r\n的判斷，所以不會影響下一幀的數據。即出錯很快就能恢復，而不是連環錯誤。 另外OBD數據命令都是AT開頭，回復數據都是$OBD開頭。
2）胎壓檢測：
數據是16進制，這樣數據長度較短，另外由于數據很簡單，所以格式是固定的長度，而且規定了每一幀的數據的開頭magic為0xA5，結束magic數為0xDD。
所以如果有一幀串口數據接收錯誤，長度錯誤例如本應10字節，結果收到5字節，那么可以通過這些，很快的恢復，所以不會影響下一幀的數據。即出錯很快就能恢復，而不是連環錯誤。

3）行車記錄儀：
數據也得考慮怎么樣才能區分出一幀、一幀的數據，如果某一幀長度接收出錯，那么如何快速區分另外一幀。快速恢復，而不連環出錯。
特別是我們還要回傳一幅圖像，那么這個十幾KB字節的數據是各種值都有可能的，要是它解析錯誤，那么后面數據就很亂了。
例如以太網，除了物理層的簡單的保證數據的起始、結束幀特征外

802.3有特征前導碼用于幀同步。而且每幀長度有各最大值。所以能快速恢復。

串口物理層，只有簡單的START和STOP簡單標記區分簡單的數據幀。需要上層協議來做幀錯誤恢復。

所以行車記錄儀數據格式可能需要考慮幀同步問題，即需要特殊的前導碼magic數。

關于制定一個通信協議：
需要考慮：
1）通訊的錯誤處理
2）如何判斷出現錯誤
3）出現錯誤如何恢復，特別是幀長度錯誤時的快速恢復。
4）一幀數據長度，最大長度值。
5）協議的完備性。
6）32位操作系統，系統快速處理，head格式最好4字節對齊。
7)時間戳方面，需要明確以什么時區為標準。另外一般系統以64位長度作為時間戳比較多。另外，unix提供的gettimeofday()一般以 Epoch為基準，即1970-01-01 00：00：00 +0000(UTC). 不清楚java是否有特殊的api進行這樣的轉換到特定時間
8)ECC
9) TLV 格式 type length value
10）安全性。

magic魔數頭的作用是，如果某幀crc校驗失敗，那么是否這幀的數據錯誤、幀頭錯誤？ 如果length就是錯的，那么你按照這個length去找流的下一幀，那么后面所有幀都不可能正常解析，這就失同步了。所以有magic頭，那么從第一個錯幀開始，搜索后面的所有數據，找magic頭，如果有，那么在按照格式去檢查，如果不對，那么說明那個magic不是magic頭，而不數據內容，只是剛好和magic頭相同而已，那么就繼續找，直到找到滿足要求的magic頭，即可以按照格式解析出正常的通過crc校驗的數據。這個找magic頭的過程叫做重新同步。 這個過程對于那種stream流式數據的幀數據分析很重要。

詳細的說明，請見：
鏈接: https://pan.baidu.com/s/1baI0oOIkM8Jd-Mh-dzDQ4w 提取碼: un1h

另外我的相關培訓視頻請看：
歡迎觀看我發布的各個課程： https://edu.51cto.com/lecturer/8896847.html

另外我的免費的linux各種驅動開發課程如下：
https://edu.51cto.com/course/17138.html

?