增量下載什么意思(計算機網絡中軟件的增量更新指的是什么)

軟件的增量更新

因為轉戰C#了,之前很多東西都丟了?，F在從頭開始弄基礎服務,首先第一個就是客戶端的自動更新。之前簡單搜了一下相關功能的實現。有一個文章我沒有看懂,另一片文章里邊說的應該是提交本地數據,然后計算差異化包,讓服務器返回差異化數據包。當然這樣不是不行?？隙ㄊ强尚械?但是對于服務器來說這部分工作可能就有點麻煩了。因為你得讓服務器有這個計算能力。參考Cocos2dx 3.9的Lua增量更新模塊,簡單做了一個基礎框架模型出來。

原來怎么做

覆蓋安裝

這個其實很簡單,就是重新下載一個完整的安裝包,然后重新安裝一遍,不管原來存不存在內容,如果原來存在內容那么久替換掉,如果原來不存在內容那么就添加上新內容就是了。其實這個說起來很簡單,但是可能會存在一些問題。

-流量問題可能現在看來這個問題并不是多么大的問題,因為現在帶寬已經非常寬了。100M的內容按照10Mpbs的帶寬來算,也就一分多鐘就能下載完了。-渣子問題這種覆蓋安裝一般會存在一個渣子的問題。比如說,我在安裝目錄里邊生成了一個不在后續安裝包的文件,那么這個文件就沒有辦法被清理掉。這就可能很尷尬了,比如說你的項目依賴系統提供的一個Dll,如果你的目錄中直接存在這個Dll那么就會優先使用你對應目錄中的Dll(如果我沒記錯應該是這樣),如果是我作為攻擊者的話,我很有可能會給你放一個我種下病毒的Dll。這就很尷尬了

打補丁

這個原理也比較簡單,其實就是我們都覺得完全安裝太費勁了,那么我的軟件又需要比較頻繁的更新,比如說某些桌游可能過個節日要上節日相關的功能,這樣就可以添加新的Dll然后又不能出一個一個的完整安裝包。那么我可以在完整安裝包的基礎上打補丁嘛。比如說,我出了版本1.0,過了十天半個月過端午了,我出個龍舟皮膚一類的,那我就可以直接在1.0的基礎上打個龍舟補丁,這樣他就變成了最新的客戶端1.1。如果將來要上別的功能了我就在1.1的基礎上打個補丁,讓客戶端變成1.2。不過這樣也會有他的問題。

-順序安裝在安裝的過程中只能以此遞增式安裝,我只能1.0=>1.1=>1.2;不能1.0=》1.2。因為中間是沒有對應的補丁的。-流量問題其實這種解決方案可能會帶來一些問題,比如說,現在端午節,我需要把房子裝飾成龍舟的樣式;然后五一勞動節,我又需要把房子裝修成五一勞動節的樣子。那么都是關于房子的皮膚,我是沒有辦法都保留的,因為來年的時候肯定就不能這么裝修了,因為過時了太Low了。那么關于這部分的內容,如果你想一點一點的升級上來對于最后的版本來說是沒用的,你占用的流量一點用都沒有。太尷尬了。-維護的復雜度因為你不能直接出了一個1.0之后全都是使用補丁,如果當你的版本號遞增到一定程度以后,補丁的大小可能遠遠超過了你重新去下載一個最新的客戶端的大小。所以只能通過時間也好(比如半年或者一個季度)通過意義(比如說大版本號2.03.0)來生成一個完整的客戶端。這樣用戶在下載的時候就可以找一個最近的完整的客戶端版本號。然后再打補丁的方式來獲得最新的客戶端,不過這種維護的復雜度應該也不小。

理理我們最核心的需求吧

其實我們的需求很簡單,獲取最新的客戶端。然后附加要求就是要省流量、下載方便、服務端發布方便。

省流量

其實說到省流量,就是能用本地的就直接使用本地。本地實在是沒有的文件,那么就從網絡上下載。這樣基本上就做到了省流量的效果。

下載方便

不需要做太多的操作,當然這個很多軟件都做到了這一點。上文中提到的其實也可以做到自動化,比如說,完整安裝的那么我就直接下載最新的完整安裝包就好了,如果是打補丁的這種,那么就下載最新的完整安裝包以及后邊的補丁就好了。其實這個真的要做,對用戶來說應該是沒有感覺得。都一樣,不過對于程序員來說?？赡苊媾R的開發就不太一樣了。

服務端發布方便

其實這個完全是針對于程序員的了,一般來說,如果這個事情可以程序來自動完成那么就肯定交給程序了。比如說完整晚裝包的這種,肯定能夠做到自動打包。打補丁的這種,無非也就是根據上一個版本生成一個補丁?；蛘咴偕梢粋€完整安裝包。上傳到合適的文件服務器就好了。其實打補丁也好,完整安裝包也好,都有一個顯著的優勢就是可以很方便的放到多個服務器上來進行文件的負載均衡。

那么我們該怎么做

在考慮這個問題的時候,我想到了之前接觸的Cocos2dx 3.9 Lua 自動更新模塊,他是這么做,通過一個配置文件,來說明最新的客戶端中都包含了那些文件,這些文件的MD5值是什么,然后網絡路徑是什么。這樣客戶端拿到這個配置清單的時候,就可以輕松的判斷本地的那些文件是可以繼續用的。那些文件是過時了的,這樣客戶端通過配置心中的網絡路徑位置獲取最新的對應文件就好了嘛。不過那也是很久之前的事情了,不然,我就不需要自己重新規劃了。直接抄一份代碼就好了嘛。還是自己整理一套吧。這樣來的更徹底一些,想改什么就改什么。

文件的格式

{"VersionsCheckCode":"XC09VU4QCRD43LRF01BYOD26D45DWEEKX5KECUKIA7Q4160FKAWQBHXTKE63Z148","TimeStamp":1496649771,"ServerUrl":"http://or2dwwrsz.bkt.clouddn.com","FileInfos":[{"FilePath":"JumpKick.HttpLib\\packages\\Moq.4.2.1409.1722\\lib\\net40\\Moq.xml","FileMD5":"c7e9c70a19b84f31e51eb65f4ee38803","FileUrl":"LV4ZBB_c7e9c70a19b84f31e51eb65f4ee38803"},{"FilePath":"JumpKick.HttpLib\\packages\\Moq.4.2.1409.1722\\lib\\sl4\\Moq.Silverlight.dll","FileMD5":"0ee20e7ccba7d6667c48efebe41503ff","FileUrl":"X057QT_0ee20e7ccba7d6667c48efebe41503ff"},{"FilePath":"JumpKick.HttpLib\\packages\\Moq.4.2.1409.1722\\lib\\sl4\\Moq.Silverlight.xml","FileMD5":"c25417228db2dd820f45e93112e8596c","FileUrl":"S0LO6G_c25417228db2dd820f45e93112e8596c"}]}

簡單的說明

• VersionsCheckCode:當前的版本文件校驗信息。

• TimeStamp:做這個文件的的時間戳

• ServerUrl:服務器的地址,主要是用來跟后續的文件進行拼接來用的

• FileInfos:對應的文件信息列表

• FileInfos[?]:FilePath:本地文件路徑,從網絡下載之后對應的本地地址

• FileInfos[?]:FileMD5:這個文件的MD5值,用來判斷原始的對應位置的文件是否與網絡中的文件相同

• FileInfos[?]:FileUrl:這個文件在網絡中存在的位置,當然這個是沒有前邊的URL路徑的是ServerUrl后邊的內容

項目地址

其實嘛整個項目最復雜的地方時這個更新的想法與這個文件的制定。剩下的內容其實就比較簡單了,就是具體的代碼的實現了。代碼方便我就懶得講了,直接把項目的地址扔上來了事。

客戶端

服務端

這樣做的好處

省流量、跟其他軟件結合方便、服務器發布方便。省流量這個上邊提到了我就說了。

跟其他軟件結合方便

其實很容易理解,就是這個軟件跟被更新的軟件一毛錢關系沒有。所以我可以直接跑起來就行了,不需要關系具體被更新的軟件是怎么搞得。最多采用這個的項目。重新改一下我們這邊的UI就行了。

服務器發布方便

其實最麻煩的事情就是服務器這邊。需要生成這個配置文件,我這邊服務器端其實并沒有在運行指的就是生成這個文件的工具。我可以指定一個目錄。然后生成這個文件,將對應目錄的所有文件導出到一個輸出目錄。不過對于很多CDN不支持多級目錄(比如七牛),所以我將所有的文件都換掉了名字,讓他們盡量的不重復,程序可讀就行了。

怎么用

首先使用我寫好的服務端生成對應的配置文件和改名文件。

生成的目錄結構是這樣色的,配置文件放到一個固定的目錄里邊去。UpLoad文件夾上傳到某一個文件服務器上,這里我是用的七牛云

然后把UpLoad目錄中的文件全都上傳上來

上傳完了就是這個樣子的。

致辭服務器就部署好了,等有了新版本重復一遍這個操作就行。其實上傳服務器的這部分工作可以集成到服務端中。上傳內容就好了嘛,其實很簡單的。當然了,這個我懶。之前也沒有研究七牛的SDK這個可以作為一個功能上的擴展,反正項目我已經開源了,感興趣的人可以自己擴展這部分功能。好吧我們繼續來說客戶端怎么弄吧。

怎么用客戶端呢

AutoUpdateHelperhelper=newAutoUpdateHelper();helper.WebXmlUrl="http://7xs9hw.com1.z0.glb.clouddn.com/VersionInfo.json";helper.ConfigXmlPath="SynchronizeVersions.xml";helper.TempXmlPath="SynchronizeVersions_Temp.xml";helper.FilePath="Client";helper.CallBack=obj=>{if(objisDictionary<UpdateDataType,object>){vardic=objasDictionary<UpdateDataType,object>;foreach(varitemindic){if(Name2Action.ContainsKey(item.Key))Name2Action[item.Key](item.Value);}}};try{helper.Start();}catch(Exceptionex){MessageBox.Show(ex.Message);}

其實就是一個簡單的設置網址跟配置文件。其實呢這個地方應該吧配置也放到配置文件里邊去,為什么沒放呢?因為我懶,哈哈哈。

客戶端的運行圖

客戶端跑完了就關了,其實應該是跑完了運行某一個具體的文件,然后自動更新的邏輯就完成了,這部分我會之后繼續完善。

不妥之處

這么樣處理其實下載會變得很靈活。但是也會帶來其他的問題。比如之前提到的打包的問題。因為服務器只是一個文件服務器,所以服務器并沒有計算出差異包的能力,所以所有的文件都是一個一個的下載的,這樣就會出現很多小文件的下載。這樣的下載其實是比較蛋疼的。這是設計上的坑。為了靈活只能妥協了。

實現的不妥之處

其實到目前為止我只是實現了最基礎的功能。甚至還不全,比如之后的文件啟動,不過大體的框架已經搭建起來了。至于后邊有很多實現不是很合理的地方,我先簡單列一列,方便之后維護。

• 下載失敗重試不存在

• 下載數量的限制不存在(現在是有多少下載多少,很多同時下載可能會存在超時的問題。)

• 完成了之后沒有啟動對應的文件

• 現在沒有快速啟動的功能(現在每次啟動都需要重新校驗所有文件,其實可以避免這個問題的。)

感謝各位的閱讀!關于“計算機網絡中軟件的增量更新指的是什么”這篇文章就分享到這里了,希望以上內容可以對大家有一定的幫助,讓大家可以學到更多知識,如果覺得文章不錯,可以把它分享出去讓更多的人看到吧!