原文轉自：http://www.360doc.com/content/14/0915/11/1073512_409611008.shtml
|
對於很多設備之間的通信，經常需要自己設計一套通信協議。當然此處的通信協議一般都是建立在TCPIP協議等協議基礎之上的協議，也就是在已有協議的基礎之上，在定義一套協議。例如：有一套檢測降雨量的設備（一般爲簡單的嵌入式設備）需要把採集到的的數據上報給中心服務器（一般爲一臺性能特別好的計算機）。就需要一套通信協議。以保證，嵌入式設備上發的數據，可以被中心服務器正確的理解和處理。再例如：在橋樑檢測的項目中，會檢測很多橋樑的數據，應力，索力，溫度等，這些檢測設備一般都是由簡單的傳感器組成的嵌入式設備 ，需要通過各種方式把採集到的的數據上報給中心服務器，中心服務器經過分析處理後，再進一步判斷橋樑的各種狀態。這些都涉及到自定義通信協議。 但這些自定義通信協議如何設計？有設計到那些方面？ 協議的設計，是爲了保證雙方能夠正常的通信，由於上位設備和下位設備一般是不同的設備，處理能力有很大差異，這些都是設計協議必須考慮的問題。 一套完整的協議，通常包含很多命令，每一個命令都會規定一個完整的命令（也就是一個完整的數據幀）包含哪些部分，一般包含以下幾部分： 1、數據幀的組成的形式 一般形式有字節流（有的地方也叫做二進制協議）和字符流。字節流一般會規定每一個字節表示的含義，而字符流由於都是可見的字符，一般會規定，字符的含義。 2、數據幀頭和尾 數據幀頭和尾其實是爲了解析數據而設計的，主要是爲了獲取一個完整的幀。由於網絡的不確定性，無法保證一條完整的數據幀的一次性就發送給對方。一般選擇用很少出現的字節或者字符作爲數據幀頭和尾。 例如我曾經解析過得MODE 04 PROTOCOL的一套協議，就是以0x03，0x14開頭的，由於MODE 04 PROTOCOL是字節流協議，因此規定了命令的開頭兩個字節是0x03，0x14，還曾經解析過字符流的協議，命令是以##開頭。數據幀尾有時會有，有時沒有，例如MODE 04 PROTOCOL就沒有協議尾，因爲它有兩個字節表示本條數據幀的長度，所以沒必要規定數據幀尾。相反，如果無法判斷一條命令的長度，就會規定數據幀如何結束。如果數據幀長度都是一樣的，也沒有必要規定，但實際中很少遇到數據幀長度是固定的情況。 3、數據幀的驗證部分 對於字節流的協議，一般會規定驗證數據幀的驗證部分，例如MODE 04 PROTOCOL就規定了數據幀最後兩個字節是crc驗證部分。 對於字符流的也可以加驗證字段，但因爲每一部分都都是可視的字符，也可以不加。 4、轉義字符 再少出現的字符由於數據幀內容的不確定性，也有可能在數據幀內部出現，例如：MODE 04 PROTOCOL協議當數據幀內部出現了0x03，0x14，也就是數據幀規定的開始部分，就必須轉義，否則就會解析出錯。導致一個數據幀變成兩部分不完整無法理解的數據幀。 5、命令字及其他 命令字就是標示此數據幀，需要完成的命令，例如：讀取時間命令數據幀，就有一部分標示此數據幀是讀取時間，設置時間命令數據幀就有一部分標示此數據幀是用來設置時間的，當然會有命令內容例如把時間調整到多少。 6、心跳包 心跳包作爲一條很特殊的數據幀，作用其實和人的心跳類似。每隔一段時間，就會發送一條很特殊的數據幀心跳包。作用就是表明此設備還在工作。 例如QQ的在上狀態應該就是通過類似心跳包的設計來完成的。但在無線領域還有其他作用，避免已經建立的鏈接斷開。尤其數據是通過GPRS發送時，如果長時間不發送數據，網絡運營商就會回收鏈接，下次發送數據時，就必須重新建立鏈接，這對於需要永遠在線的設備或者是需要隨時喚醒的設備來說，顯然是不行的。 對比： 字節流協議難度顯然比字符流大很多，解析過程也更復雜，如果沒有協議文檔，幾乎不能解析，因爲收到的就是一串毫無意思的數字，一個字節處理錯誤就完全可能導致整條數據解析錯誤，此外字節流還需要規定大端模式和小端模式等。當然好處就是，傳輸同樣的信息，數據量明顯少很多。 字符流就簡單很多，解析的過程可能就是一個正則表達式。 |