[發明專利]映像文件的補包方法

無效

• 申請號: 201010158779.1
• 申請日: 2010-04-23
• 公開（公告）號: CN102238206A
• 公開（公告）日: 2011-11-09
• 發明（設計）人: 劉曉鵬;吳樹桂;李連成;呂健;陳志豐
• 申請（專利權）人: 英業達集團(天津)電子技術有限公司;英業達股份有限公司
• 主分類號: H04L29/08
• 分類號: H04L29/08;H04L29/06;H04L12/56
• 代理公司: 北京律誠同業知識產權代理有限公司 11006
• 代理人: 梁揮;張燕華

技術領域

本發明涉及一種文件的補包方法，特別是一種映像文件的補包方法。

背景技術

隨著網絡的快速發展，使得許多映像備份(image)也加入網絡傳輸的機制。在許多計算器裝置的生產廠商為了能快速的安裝計算器裝置的系統，多會利用網絡映像備份來進行生產在線各計算器裝置的系統安裝。在一般的網絡映像備份程序中多以組播(multicast)技術作為傳輸手段。

所謂組播是指數據只傳輸給屬于某同一群體的成員們。其中，這些成員可能分布在不同的局域網絡上，并且具有相同的網絡地址。組播會比一次只對一個網絡節點作傳輸的單一傳播(unicast)，更節省網絡頻寬和網絡地址的使用。

由于組播的不可靠性再加上網絡狀況和客戶端等諸多因素的影響，使得數據封包(package)在傳輸的過程中常會發生丟失。但映像備份的目的必須保持數據的完整性，因此丟失的數據封包必須由伺服端進行重發。一般的組播重發機制包括以下步驟，請參考圖1所示，其為現有技術的運作流程示意圖：伺服端將數據封包進行編號按順序發送(步驟S110)，并將編號記錄在數據封包中。客戶端在收到數據封包后并讀取其編號(步驟S120)。如果與上一次收到的數據封包的編號不連續，即判定為資料封包丟失。隨后，客戶端以傳輸控制協議(Transmission?control?protocol，以下簡稱TCP)請求的方式要求伺服端重新發送丟失的數據封包(步驟S130)。

這種機制的缺陷在于：由于TCP的傳輸相較于組播速度要慢得多。所以當網絡狀況不佳且數據封包丟失比較頻繁時，傳輸效率會大幅降低。若是數據封包的丟失多發生在交換器(switch)或其它網絡網關設備時，這樣會使得此一網域中的客戶端都無法接收到相同的數據封包。這時候網域中所有的客戶端會要求伺服端重送遺漏的數據封包。因而造成伺服端在同一時間中收到大量TCP請求，使得伺服端壓力嚴重增加。

發明內容

本發明所要解決的技術問題是提供一種映像文件的補包方法，應用于生產在線的計算器中，在更新計算器的映像文件時，對映像文件所缺漏的部分數據進行重新補發。

為了實現上述目的，本發明提供了一種映像文件的補包方法，應用于生產在線的一計算器中，其中，通過一多播傳輸協議用以更新該計算器的一映像文件時，對該映像文件所缺漏的部分數據進行重新補發，該映像文件的補包方法包括以下步驟：

步驟a.由一伺服端將該映像文件劃分為多個塊數據，每一該塊數據具有相應的一區塊編號與多個傳輸封包，該傳輸封包具有一封包編號；

步驟b.該客戶端接收該些傳輸封包，并依照該封包編號的順序重組為相應的該塊數據；

步驟c.當該塊數據中缺漏部分的該些傳輸封包時，則該客戶端向該伺服端提報一重發請求，以重新傳送該塊數據所缺漏的該些傳輸封包；

步驟d.該伺服端收集該些客戶端所缺漏的該些傳輸封包，并將該些傳輸封包進行統計，產生一統計列表；

步驟e.由該伺服端根據該統計列表與一重傳閥值，決定該傳輸封包的一傳送協議，用以將該傳輸封包傳送至相應的該客戶端；以及

步驟f.該客戶端接收來自該伺服端重新傳送的該傳輸封包，補齊所有缺漏的該些傳輸封包為止。

上述的映像文件的補包方法，其中，該客戶端接收該些傳輸封包的步驟中還包括以下步驟：

對依序接收的該些塊數據與所屬的該些傳輸封包，依據兩個該塊數據的該傳輸編號判斷接收順序；

當兩個該塊數據的該傳輸編號順序不一致時，依據該些傳輸封包的該封包編號判斷接收順序；以及

當該些傳輸封包的接收順序發生缺漏時，則記錄缺漏的該些傳輸封包。

上述的映像文件的補包方法，其中，該伺服端收集該些客戶端所缺漏的該些傳輸封包的步驟中還包括以下步驟：

對每一該客戶端所發出的該重發請求執行一雜湊程序，并將已經過該雜湊程序的該重發請求記錄于該統計列表中；以及

若該統計列表中已存在相同的記錄時，則將相同記錄的該重發請求合并。

上述的映像文件的補包方法，其中，決定該傳輸封包的該傳送協議的步驟中還包括：

當相同的該傳輸封包的總數量小于該重傳閥值時，則該伺服端利用該多播傳輸協議傳送該傳輸封包給相應的該客戶端；以及

當相同的該傳輸封包的總數量大于該重傳閥值時，則刪除此一該重發請求。

上述的映像文件的補包方法，其中，該重傳閥值根據下式所決定：