王偉軍
(四川長虹網絡科技有限責任公司 四川省綿陽市 621000)
隨著軟件技術的日益發展,嵌入式軟件系統的發展也在日益更新。對于嵌入式產品如機頂盒、IPTV電視等產品,操作系統的已經從輕量級系統如OS21, OS40, UCOS, ECOS發展到Linux,Android功能更全面更復雜的系統,而隨著操作系統越來越高級功能越來越全面,也造成了系統鏡像文件越來越大,以至于生產升級所需要的時間也隨之變長,這就給生產升級維護提出了新的要求。
在工廠生產階段,為加快生產進度,通常做法是先預裝基礎軟件,機器上線生產調試完成后再升級成最終版本的軟件。而對于這些采用如Android操作系統的機器,升級鏡像文件動輒幾百M甚至上Gb的大小。如采用傳統升級方式如TS流、TFTP或 HTTP等升級方式,因受限于協議機制或網絡狀況,數據傳輸不穩定且下載速度太慢,或數據下載進度不同步,從而導致生產效率低下,不適用于工廠生產階段使用。因此有必要尋找一種下載速度快,下載穩定,操作簡便的方式來滿足工廠升級的需要。
在計算機網絡中,有三種基本的通信方式:單播、組播、廣播。其中單播屬于點對點通信不使用一對多大文件的傳輸,廣播屬于點對所有點的通信,而組播則是介于兩者之間,是是一種點對多的通訊方式,由一個主機向一組主機發送消息,首先一臺主機將數據發送到一個約定的組播組中,然后網絡路由器和交換機將組播組中的數據復制到其它加入此組播的主機。一個主機用組播協議向多個主機發送相同的數據時,只需要發送一次,其數據由網絡中的路由器和交換機逐級進行復制并發送給各個接收方,這樣既節省網絡硬件資源,也節省主干網絡的帶寬資源。并且與廣播協議相比,只有組播接收方向路由器發出請求后,網絡路由器才復制一份數據給接收方,對帶寬的需求恒定,從而節省接收方的帶寬。而廣播方式無論接收方是否需要,網絡設備都會將廣播信息向所有設備發送,占據大量帶寬。嚴重時會造成網絡阻塞甚至廣播風暴。
當然,組播也有其固有的缺點,組播協議是基于UDP的,UDP采用的無連接,數據報的連接方式,它只管發送數據而不關心接收方是否能夠收到;UDP包是無序列號,傳輸時可能出現無序性,缺乏流控功能;也無窗口機制,會導致收到重復組播流量。但是也正是因為UDP不用保證數據的可靠性,所有數據的傳送效率是很快的。與單播協議相比,因為組播采用的是UDP的傳輸方式,所有沒有補包機制,無法有對錯包漏包的進行重傳補包。雖然組播有其缺點,但是根據特定場景,組播也有其優勢:當需要將大量相同的數據傳輸到不同主機時,能節省發送數據的主機的系統資源和帶寬;組播是有選擇地將數據復制給有要求的主機;組播能節省網絡主干的帶寬資源;而它缺點也可以根據具體需求忽略,或通過合適的設計方案來規避。因此只要通過合理設計,組播方式升級也將是一種可行方案。
機頂盒局域網組播升級方案,主要用于工廠批量升級。有以下這些要求:數據需要自動循環發送滿足多輪次升級要求;機器開機時需自動進行升級檢測,程序根據配置的信息自動判斷是否進行升級操作,減少人員操作次數;對于500M及以上鏡像文件的升級,單臺升時間控制在3分鐘左右完成,其中包括:機器啟動,升級檢測,數據下載,數據校驗,數據寫入,重啟驗證等步驟,因此要求下載速度達到10 Mbyte/s來保證效率;需要保證下載進度基本達到同時開始同時結束的要求以便于流水線操作;升級過程中的狀態需要對各個機器的升級狀態進行顯示以利于實時抽檢;升級后的機器日志信息上傳到數據庫中存儲用于校驗和后續維護;整個系統需要方便部署操作簡單便于人工操作。
按照以上組播特點結合實際要求,本文設計了一種數據處理機制,用于組播輪播升級的系統。整個系統采用C/S服務器/客戶端模式,分別實現組播數據發送端(即服務端)和數據接收端(即客戶端);約定好數據發送和接受機制,使用UDP進行數據包的接收和發送;根據組播地址分配原則,選擇本地管理組播地址段為239.0.0.0~239.255.255.255進行組播數據通信。
數據文件在升級過程中,不僅僅需要考慮文件本身安全性和完整性,還需要考慮接收的文件是否與本機狀態信息匹配,因此,特為組播數據的傳輸設計兩種類型的表格:為下載信息描述表格Download Server Info Section和下載數據表格Download Server Data Section,分別簡記為DSIS和DDBS表格。
考慮到程序的通用性和可移植性,這兩種表格的格式參照PSI/SI標準的表格的格式進行定義,其中,在DSIS表格中包含了軟件適用的廠商ID,型號,硬件版本,軟件版本,批次,類型,序列號等控制信息,以及升級文件的長度,校驗,控制類型,加密類型,StreamID等信息,這些信息可通過工具界面或配置文件進行設置。
在DDBS表格中,由于以太網(Ethernet)鏈路層的MTU(最大傳輸單元)的最大長度為1500字節,而當UDP包中的數據多于MTU(1500 - IP頭(20) - UDP頭(8) = 1472(字節))時,發送方的IP層需要分片進行傳輸,在接收方IP層則需要進行數據報重組,而由于UDP是不可靠的傳輸協議,如果分片丟失導致重組失敗,將導致UDP數據包被丟棄數據重傳浪費時間,所以此處選擇將數據包定義為最大1500字節,減少數據重傳的資源消耗。
將DSIS表格和DDBS表格按照一定格式和順序組裝成stream流數據,通過UDP協議向組播組中進行循環播放。接收端則按照以下方式接收和處理表格信息:
信息表格處理流程:DSIS表格作為監控表格,接收方連接網絡后,循環監控組播組中指定端口,當接收到了DSIS表格后,先校驗表格,解析出表格中的版本信息和控制信息等,判斷是否符合本機的升級條件。如符合升級條件,則解析出新軟件的文件信息和流控StreamID信息,然后進入DDBS的下載流程。
數據表格處理流程:接收方從組播組中接收指定端口的UDP數據,校驗DDBS表格成功后,然后根據section_number和section_length來定位當前包在文件中的地址并組裝到文件中。數據下載完成后,對數據完整性校驗和安全性驗證,驗證成功后解析出原始升級鏡像文件。最后,進入數據存儲流程完成升級操作。

圖1:網絡搭建示意圖
組播中傳輸數據分為DDIS (下載信息描述表格)和DDBS(下載數據描述表格) 兩種表格。其中DSIS表中存放的是升級參數信息和升級文件信息,DDBS表中存放的是固定大小的文件數據的分段。
服務端先設置好升級參數信息并計算升級數據文件信息,分別生成DSIS和DDBS表格。將下載信息描述封裝到DSIS表中,下載數據封裝到DDBS表格中。
服務端按照一定次序發送DSIS,DDBS表格,將DSIS表格按照一定間隔插播到DDBS表格的發送間隔進行發送,以提高客戶端中的DSIS信息表格的獲取效率,保證機器在任何時刻都能檢測到升級信息并進行數據下載。
將下載數據拆分成1472字節(能保證本地局域網環境傳輸UDP包可靠的參考MTU值)的分段,然后按照輪播的方式循環發送,保證同一批機器能基本同時完成升級操作。
服務端同時開啟一個守護進程,用來監聽數據回傳端口,當接收到客戶端發來的回傳數據時,實時顯示到界面并同步更新到數據庫中,用于實時診斷和后期維護。
數據收發需要約定好組播組IP地址段(局域網私有段為239.0.0.1~239.255.255.255)和端口號,數據輪播直至服務器關閉。
有些系統默認是不接收組播消息的,所以客戶端進行組播升級時先確認打開組播模式。
首先客戶端機器開機,網絡功能初始化成功后,初始化升級組播監控模式,建立組播socket,綁定端口,加入到組播組(按約定或從其他途徑配置);為減少系統資源消耗,組播監控一段時間仍未檢測到升級信息,則退出組播監控流程。
客戶端機器連接組播服務成功后,上報本機信息,包括版本號,序列號,MAC號,控制碼等參數信息;
連接組播網絡并接收UDP組播數據。先接收DSIS表格,從中解析出升級信息,如果本機滿足升級條件,則從中解析出DDBS數據流的StreamID;
使用DSIS中解析的StreamID過濾來DDBS表格,循環接收DDBS數據并組裝還原成鏡像文件,下載完成后校驗數據完整性和安全性,校驗成功后存儲到機器FLASH或SD卡中;
設置recovery升級標志,進入Recovery模式進行系統升級更新,升級完成后機器重啟。
二次重啟后,客戶端重復第一步連接操作,再次上報參數信息并接收DSIS表格,通過比較判斷軟件是否更新成功,退出組播監控,程序進入正常運行階段,升級完成。
設備需求:電腦,路由器,網線若干,顯示設備。
網絡搭建示意圖如圖1所示。
電腦服務器連接到路由器,路由器連接到交換機,路由器或交換機連接到機頂盒終端;交換機并不是必須的,只有在路由器LAN端口不夠用的情況下可以通過交換機擴展端口;路由器與機頂盒處于同一個地址段。
實際使用時,由專業人員搭建好升級網絡,操作人員只需要連接設備端電源和網線,然后等待升級完成后進入下一批機器升級。因組播數據下載速度快,升級耗時減少,可以持續循環操作,提升效率,還可采用了流水作業方式進一步提高效率。
數據組播方式,通過合理設計后可用于生產批量升級,在生產升級過程中能極大節省時間并提高生產效率。自動化的升級處理流程也簡化了操作流程,降低對生產人員的技能要求,降低工作復雜度。