您好,登錄后才能下訂單哦!
這篇“ServerSuperIO持續傳輸大塊數據流的兩種方式是什么”文章的知識點大部分人都不太理解,所以小編給大家總結了以下內容,內容詳細,步驟清晰,具有一定的借鑒價值,希望大家閱讀完這篇文章能有所收獲,下面我們一起來看看這篇“ServerSuperIO持續傳輸大塊數據流的兩種方式是什么”文章吧。
以現在物聯網的現狀或是對物聯網的認知,特別是工業物聯網,必須具備集成多種數據源的能力。數據源大體分兩類:硬件產生和軟件產生。如下圖:
基于現實情況,作為物聯網框架必須具備各類數據的集成能力,以及各種應用場景。以數據大小為例,小到一次接收緩存承載能力范圍內的數據,大到超出一次接收緩存承載能力范圍的數據,只要網絡允許,都有可能。以前的連載文章都是以小的數據包為基礎介紹的,這篇文章介紹大塊數據流的傳輸方式。
這種方式是規定好數據包協議的開頭和結尾,把大塊數據分解成一定長度的小數據包,以協議頭+小數據包+協議尾的組合方式分批次進行數據傳輸。接收到每個批次的數據后,再進行數據校驗,拼裝數據,還原出完整的數據。示意圖如下:
這種方式存在以下幾個問題:
(1) 每個包的數據出現問題后,要進行數據補發。要設計好協議,完成補發機制。
(2)數據源是多種多樣的,例如:壓縮文件、序列化的文件、加密的文件等等,那么就存在每個小數據包的數據有可能會和協議頭或協議尾一致,甚至和CRC校驗一致的情況,從而導致數據無法正常校驗和解析,這時進行補發數據,可能出現同類情況是大概率事件。
選擇這種傳輸大塊數據流的方式,要根據現場的實際情況進行選擇,規避可能出現的風險,提高項目、產品整體的穩定性。
如果選擇這種方式,那么根據前面介紹的文章,就可以實現,網友可以自己動手實現。這篇文章主要介紹下面這種方式。
客戶端先發送請求發送數據的命令,并且在命令標識本次要發送數據的長度。如果服務端接收到該請求命令后,根據判斷請求數據長度是否在允許范圍內,然后返回相同命令數據或其他確認數據給客戶端,標識是否允許發送該長度的數據信息。如果可以發送,那么客戶端則持續發送數據流,服務端也進行持續接收階段。示意圖如下:
針對這種數據傳輸的方式,ServerSuperIO專門提供了接口。下面進行詳細的介紹。
請求發送0x62指令,共10個字節,校驗和為從“從機地址”開始的累加和,不包括“數據報頭”、“校驗和”和“協議結束”。
請求指令數據幀如下:
服務端接收到該請求命令后,返回同樣的命令信息給客戶端,客戶端則進入持續發送數據的狀態。
先發送請求數據命令,代碼如下:
+ View Code
接收到服務端的確認信息后,持久發送數據的代碼如下:
+ View Code
客戶端的代碼實現基本上沒有什么好講的,主要是介紹基于ServerSuperIO框架,以設備驅動的方式是怎么實現的。注:以下自控模式實現。
1. 協議接口的實現
DeviceProtocol:ProtocolDriver接口有一個GetPackageLength(byte[] data, IChannel channel, ref int readTimeout)函數接口,data參數是請求發送數據的命令,channel參數是當前IO通道的實例,readTimeout是自定義返回接收數據長度所要使用的時間,如果返回值為0的話,則認為不進入持續接收數據任務。可以通過channel參數直接返回確認信息,具體代碼如下:
+ View Code
2. 協議命令的實現
為了實現對大塊數據的處理,專門增加一個協議命令,用于解析、保存數據。代碼如下:
+ View Code
3. 設備驅動調用協議,并驅動協議命令
在接收大塊數據流的時候,會把所有數據信息返回到設備驅動的Communicate接口,其中info參數的Data是當前請求數據的命令,BigData就是持續接收數據的信息,通過調用this.Protocol.DriverAnalysis協議接口驅動協議命令DeviceFileCommand。具體代碼如下:
+ View Code
4. 宿主程序服務實例配置注意事項
主要在配置參數中配置StartCheckPackageLength = true,在接數據的過程中會檢測相應設備驅動的協議接口GetPackageLength。
+ View Code
圖片
以上就是關于“ServerSuperIO持續傳輸大塊數據流的兩種方式是什么”這篇文章的內容,相信大家都有了一定的了解,希望小編分享的內容對大家有幫助,若想了解更多相關的知識內容,請關注億速云行業資訊頻道。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。