通用軟件更新系統設計
前言：本站為你精心整理了通用軟件更新系統設計范文，希望能為你的創作提供參考價值，我們的客服老師可以幫助你提供個性化的參考范文，歡迎咨詢。
編者按：本論文主要從問題的提出；問題的分析；HTTP協議特點；數據流程及數據結構；客戶端工作流程等進行講述，包括了客戶端運行的版本也越來越雜、創建自動升級程序的線程、網絡狀況很差的時候更新所需要的時間很長、因為整體打包之后會出現客戶端只需要更新一個文件而不得不下載整個壓縮包的情況等，具體資料請見：
摘要：針對桌面應用程序在之后版本難以維護的問題，提出了基于HTTP協議的解決方案，并對該解決方案進行了深入研究。提取出通用的自動更新平臺，對解決版本維護難題有一定的參考意義。
關鍵詞：自動升級；更新平臺；網絡更新
1問題的提出
隨著桌面應用程序新版本的不斷，客戶端運行的版本也越來越雜，版本、數據結構的兼容也成為后續開發必須考慮的問題，而且兼容性方面的問題越來越多，開發及維護成本越來越高。
2問題的分析
隨著因特網的普及，通過網絡來實現桌面應用程序的更新升級已經成為可能。在程序中加入在線更新的功能將能有效地解決前面討論的版本維護難題。
關于通信協議，可以編寫程序實現Socket通信，也可以采用比較成熟的HTTP協議。考慮到諸多因素，筆者選擇了HTTP協議。
3HTTP協議特點
HTTP協議（超文本傳輸協議）的主要特點可概括如下：
(1)簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑。請求方法常用的有GET、HEAD、POST。每種方法規定了客戶與服務器聯系的類型不同。
(2)由于HTTP協議簡單，使得HTTP服務器的程序規模小，因而通信速度很快。
(3)靈活：HTTP允許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type加以標記。
(4)無連接：無連接的含義是限制每次連接只處理一個請求。服務器處理完客戶的請求，并收到客戶的應答后，即斷開連接。采用這種方式可以節省傳輸時間。
(5)無狀態：HTTP協議是無狀態協議。無狀態是指協議對于事務處理沒有記憶能力。缺少狀態意味著如果后續處理需要前面的信息，則它必須重傳，這樣可能導致每次連接傳送的數據量增大。另一方面，在服務器不需要先前信息時它的應答就較快。
另外，筆者在實驗中發現很多網絡都設置了防火墻，考慮到安全問題，網絡管理員會屏蔽很多端口。而對于HTTP最常用的80端口通常是開放的，這也是筆者選擇HTTP協議的一個重要因素。
4數據流程及數據結構
實際應用中可以對流程進行擴展，例如自動程序線程定時啟動、開始更新前檢查上次留下的緩存、斷點續傳等。
該平臺中有多個軟件產品，存儲在U_Products表中。每個軟件產品有多個用于客戶端驗證的序列號，存儲在U_Clients。序列號是客戶端的憑證，只有授權了的序列號才能訪問平臺。而且序列號表還標出了該序列號允許升級的版本范圍。同時，每個軟件產品對應的多個文件，通過服務端腳本輸出一個文件列表。客戶端連接上服務器后首先要做的就是下載屬于它的文件列表。
文件列表用于比較客戶端文件與服務器上的各個文件的新舊。其中的時間戳是主要比較字段，文件名用于記錄定位。
5客戶端工作流程
需要指出的是表1列出的是基本的流程。實際中客戶端工作流程會比表1復雜的多。
主程序啟動之后，創建自動升級程序的線程。該線程在后臺運行，首先讀出產品的序列號，通過URL參數傳值的形式傳到Web端。此處傳值可以更加靈活，可以在用戶允許的前提下，將更多的信息傳給服務器。例如當前軟件版本，客戶端操作系統版本，客戶端計算機硬件信息等等。
運行在Web端的腳本響應請求，判斷序列號是否合法，即序列號是否正確，是否過期。通過之后輸出與該序列號對應的軟件的所有文件列表。
自動升級程序開始通過HTTP協議下載這個列表。下載完畢后讀出上一次升級之后，保存下來的文件列表，并與下載下來的列表進行對比，通過時間戳對比找出新文件。通常只要時間戳不一樣就將文件加入的需要下載的文件列表中，也可以采用時間戳轉成浮點數后大小對比的策略。例如平臺中放的是穩定的正式版，而有些客戶端已經通過其他途徑得到新版本更高的測試版。第二種策略就可以避免高版本文件通過升級之后版本降低。這也是為什么采用時間戳，而不是文件MD5唯一哈希值的原因。
得到新文件列表之后，再次通過HTTP協議逐一下載新文件到緩存目錄中。下載新文件的URL由文件編號和序列號共同確定。每下載一個文件，更新一次本地的文件列表。這樣如果出現網絡中斷，用戶退出等異常，下次啟動可以跳過已經下載過的文件。雖然這不是嚴格意義上的斷點續傳，但在一定程度上提高了程序的容錯能力。
數據全部下載完畢之后詢問用戶是否立即應用更新。如果是則退出主程序，將緩存文件夾中的文件移動到主程序所在的目錄中，并覆蓋。否則保持緩存中的文件，供下次升級使用。
6改進及結束語
網絡狀況很差的時候更新所需要的時間很長。對于該問題，可以對文件進行逐個ZIP壓縮，通過HTTP協議傳輸壓縮流，而不是文件本身的數據流。客戶端下載之后進行解壓縮。此處是對文件逐個壓縮，而不是整體打包。因為整體打包之后會出現客戶端只需要更新一個文件而不得不下載整個壓縮包的情況。而且整體打包也對斷點續傳提出了更高的要求。
另外出于某種原因的考慮，有時需要更多考慮數據安全。例如未授權的序列號不能獲得新版本的文件，且一個序列號只能對應一個客戶端。對此可以采用動態序列號的方式，即下載完文件列表時或更新結束時，都將原有的序列號作廢，動態創建一個新的值。
另外對于重大缺陷的修復更新，更希望能強制更新。對此可以在自動更新程序發現更新時，強制停止主程序的響應。通過這一策略甚至可以做到所有的新版本之后，客戶端迅速跟進，并全部更新到最新版本。
筆者使用微軟的C#語言來實現，經過反復測試，發現ZIP壓縮之后，對網絡要求低了很多，更新效率提高很多。通過動態序列號及強制更新策略也基本能保證客戶端版本可控。
