這篇“ServerSuperIO持續(xù)傳輸大塊數(shù)據(jù)流的兩種方式是什么”文章的知識點(diǎn)大部分人都不太理解，所以小編給大家總結(jié)了以下內(nèi)容，內(nèi)容詳細(xì)，步驟清晰，具有一定的借鑒價(jià)值，希望大家閱讀完這篇文章能有所收獲，下面我們一起來看看這篇“ServerSuperIO持續(xù)傳輸大塊數(shù)據(jù)流的兩種方式是什么”文章吧。

網(wǎng)站建設(shè)哪家好，找創(chuàng)新互聯(lián)！專注于網(wǎng)頁設(shè)計(jì)、網(wǎng)站建設(shè)、微信開發(fā)、重慶小程序開發(fā)公司、集團(tuán)企業(yè)網(wǎng)站建設(shè)等服務(wù)項(xiàng)目。為回饋新老客戶創(chuàng)新互聯(lián)還提供了沈河免費(fèi)建站歡迎大家使用！

10．持續(xù)傳輸大塊數(shù)據(jù)流的兩種方式（如：文件）

10.1     概述

    以現(xiàn)在物聯(lián)網(wǎng)的現(xiàn)狀或是對物聯(lián)網(wǎng)的認(rèn)知，特別是工業(yè)物聯(lián)網(wǎng)，必須具備集成多種數(shù)據(jù)源的能力。數(shù)據(jù)源大體分兩類：硬件產(chǎn)生和軟件產(chǎn)生。如下圖：

    基于現(xiàn)實(shí)情況，作為物聯(lián)網(wǎng)框架必須具備各類數(shù)據(jù)的集成能力，以及各種應(yīng)用場景。以數(shù)據(jù)大小為例，小到一次接收緩存承載能力范圍內(nèi)的數(shù)據(jù)，大到超出一次接收緩存承載能力范圍的數(shù)據(jù)，只要網(wǎng)絡(luò)允許，都有可能。以前的連載文章都是以小的數(shù)據(jù)包為基礎(chǔ)介紹的，這篇文章介紹大塊數(shù)據(jù)流的傳輸方式。

10.2     大塊數(shù)據(jù)流的兩種傳輸方式

10.2.1 協(xié)議數(shù)據(jù)包的方式

    這種方式是規(guī)定好數(shù)據(jù)包協(xié)議的開頭和結(jié)尾，把大塊數(shù)據(jù)分解成一定長度的小數(shù)據(jù)包，以協(xié)議頭+小數(shù)據(jù)包+協(xié)議尾的組合方式分批次進(jìn)行數(shù)據(jù)傳輸。接收到每個批次的數(shù)據(jù)后，再進(jìn)行數(shù)據(jù)校驗(yàn)，拼裝數(shù)據(jù)，還原出完整的數(shù)據(jù)。示意圖如下：

     這種方式存在以下幾個問題：

       （1） 每個包的數(shù)據(jù)出現(xiàn)問題后，要進(jìn)行數(shù)據(jù)補(bǔ)發(fā)。要設(shè)計(jì)好協(xié)議，完成補(bǔ)發(fā)機(jī)制。

       （2）數(shù)據(jù)源是多種多樣的，例如：壓縮文件、序列化的文件、加密的文件等等，那么就存在每個小數(shù)據(jù)包的數(shù)據(jù)有可能會和協(xié)議頭或協(xié)議尾一致，甚至和CRC校驗(yàn)一致的情況，從而導(dǎo)致數(shù)據(jù)無法正常校驗(yàn)和解析，這時(shí)進(jìn)行補(bǔ)發(fā)數(shù)據(jù)，可能出現(xiàn)同類情況是大概率事件。

     選擇這種傳輸大塊數(shù)據(jù)流的方式，要根據(jù)現(xiàn)場的實(shí)際情況進(jìn)行選擇，規(guī)避可能出現(xiàn)的風(fēng)險(xiǎn)，提高項(xiàng)目、產(chǎn)品整體的穩(wěn)定性。

     如果選擇這種方式，那么根據(jù)前面介紹的文章，就可以實(shí)現(xiàn)，網(wǎng)友可以自己動手實(shí)現(xiàn)。這篇文章主要介紹下面這種方式。

10.2.2 請求長度、確認(rèn)的方式

   客戶端先發(fā)送請求發(fā)送數(shù)據(jù)的命令，并且在命令標(biāo)識本次要發(fā)送數(shù)據(jù)的長度。如果服務(wù)端接收到該請求命令后，根據(jù)判斷請求數(shù)據(jù)長度是否在允許范圍內(nèi)，然后返回相同命令數(shù)據(jù)或其他確認(rèn)數(shù)據(jù)給客戶端，標(biāo)識是否允許發(fā)送該長度的數(shù)據(jù)信息。如果可以發(fā)送，那么客戶端則持續(xù)發(fā)送數(shù)據(jù)流，服務(wù)端也進(jìn)行持續(xù)接收階段。示意圖如下：

     針對這種數(shù)據(jù)傳輸?shù)姆绞?，ServerSuperIO專門提供了接口。下面進(jìn)行詳細(xì)的介紹。

10.3     實(shí)現(xiàn)持續(xù)傳輸大塊數(shù)據(jù)

10.3.1 設(shè)計(jì)請求發(fā)送數(shù)據(jù)協(xié)議

    請求發(fā)送0x62指令，共10個字節(jié)，校驗(yàn)和為從“從機(jī)地址”開始的累加和，不包括“數(shù)據(jù)報(bào)頭”、“校驗(yàn)和”和“協(xié)議結(jié)束”。

    請求指令數(shù)據(jù)幀如下：

    服務(wù)端接收到該請求命令后，返回同樣的命令信息給客戶端，客戶端則進(jìn)入持續(xù)發(fā)送數(shù)據(jù)的狀態(tài)。

10.3.2 客戶端代碼實(shí)現(xiàn)

    先發(fā)送請求數(shù)據(jù)命令，代碼如下：

+ View Code

     接收到服務(wù)端的確認(rèn)信息后，持久發(fā)送數(shù)據(jù)的代碼如下：

+ View Code

10.3.3 ServerSuperIO框架的實(shí)現(xiàn)及注意事項(xiàng)

     客戶端的代碼實(shí)現(xiàn)基本上沒有什么好講的，主要是介紹基于ServerSuperIO框架，以設(shè)備驅(qū)動的方式是怎么實(shí)現(xiàn)的。注：以下自控模式實(shí)現(xiàn)。

1. 1.      協(xié)議接口的實(shí)現(xiàn)

      DeviceProtocol:ProtocolDriver接口有一個GetPackageLength(byte[] data, IChannel channel, ref int readTimeout)函數(shù)接口，data參數(shù)是請求發(fā)送數(shù)據(jù)的命令，channel參數(shù)是當(dāng)前IO通道的實(shí)例，readTimeout是自定義返回接收數(shù)據(jù)長度所要使用的時(shí)間，如果返回值為0的話，則認(rèn)為不進(jìn)入持續(xù)接收數(shù)據(jù)任務(wù)?？梢酝ㄟ^channel參數(shù)直接返回確認(rèn)信息，具體代碼如下：

+ View Code

 2.      協(xié)議命令的實(shí)現(xiàn)

   為了實(shí)現(xiàn)對大塊數(shù)據(jù)的處理，專門增加一個協(xié)議命令，用于解析、保存數(shù)據(jù)。代碼如下：

+ View Code

1. 3.      設(shè)備驅(qū)動調(diào)用協(xié)議，并驅(qū)動協(xié)議命令

     在接收大塊數(shù)據(jù)流的時(shí)候，會把所有數(shù)據(jù)信息返回到設(shè)備驅(qū)動的Communicate接口，其中info參數(shù)的Data是當(dāng)前請求數(shù)據(jù)的命令，BigData就是持續(xù)接收數(shù)據(jù)的信息，通過調(diào)用this.Protocol.DriverAnalysis協(xié)議接口驅(qū)動協(xié)議命令DeviceFileCommand。具體代碼如下：

+ View Code

1. 4.      宿主程序服務(wù)實(shí)例配置注意事項(xiàng)

     主要在配置參數(shù)中配置StartCheckPackageLength = true,在接數(shù)據(jù)的過程中會檢測相應(yīng)設(shè)備驅(qū)動的協(xié)議接口GetPackageLength。

+ View Code

10.4     運(yùn)行效果

圖片

以上就是關(guān)于“ServerSuperIO持續(xù)傳輸大塊數(shù)據(jù)流的兩種方式是什么”這篇文章的內(nèi)容，相信大家都有了一定的了解，希望小編分享的內(nèi)容對大家有幫助，若想了解更多相關(guān)的知識內(nèi)容，請關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。