文件傳輸方法與流程
2023-06-20 19:26:51

本發明涉及數據傳輸技術領域,尤其涉及一種文件傳輸方法。
背景技術:
在交通顯示控制系統領域,當前網絡數據傳輸都是採用專網專線,除了對數據傳輸的安全性要求比較高之外,對數據的可靠性傳輸也是要求比較高的,這樣的話,就需要考慮一些網絡數據傳輸可靠性的冗餘性,才能更加可靠的保證數據的可靠性傳輸。
當前在交通行業中,一般的LED控制系統在進行數據交互時基本上都是採用單獨的HTTP協議數據傳輸、單獨的FTP文件傳輸協議或用戶自定義的一些非標準的文件傳輸協議等進行媒體數據傳輸。
在TCP/IP協議中,FTP標準命令TCP埠號為21,數據埠為20。FTP的任務是從一臺計算機將文件傳送到另一臺計算機,不受作業系統的限制。FTP的傳輸有兩種方式:ASCII傳輸方式和二進位傳輸方式。
ASCII傳輸方式為:假定用戶正在拷貝的文件包含的是簡單ASCII碼文本,如果在遠程計算機上運行的不是UNIX系統,當文件傳輸時FTP通常會自動地調整文件的內容以便把文件解釋成另外那臺計算機存儲文本文件的格式;但是常常有這樣的情況,用戶正在傳輸的文件包含的不是文本文件,而可能是程序、資料庫、字處理文件或者壓縮文件;在拷貝任何非文本文件之前,發送端用Binary命令告訴FTP逐字拷貝。
二進位傳輸模式為:在二進位傳輸中保存文件的位序,以便原始和拷貝的是逐位一一對應的,即使目的地計算機機上包含位序列的文件是沒意義的。例如Macintosh系統以二進位方式傳送可執行文件到Windows系統,在對方系統上此文件不能執行。
如果在ASCII方式下傳輸二進位文件,即使不需要也仍會自動轉譯,這會導致數據損壞,其原因是ASCII傳輸方式一般假設每一字符的第一有效位無意義,因為ASCII字符組合不使用它;但是如果傳輸的是二進位文件,所有的位都是重要的。
FTP協議允許在使用不同文件系統的計算機之間進行數據傳送,儘管該協議在傳送數據中提供了很高的靈活度,它仍然不會嘗試保留特定於某個文件系統的文件屬性(如文件保護模式或修改時間);而且FTP協議為文件系統的整體結構做了少許假設,且不提供或不允許諸如循環地複製子目錄這樣的函數。
再者,FTP是一個8位的客戶端-伺服器端協議,能操作任何類型的文件而不需要進一步處理,就像MIME(Multipurpose Internet Mail Extensions,多用途網際網路郵件擴展)或Unicode一樣。但是,FTP有著較高的延時,這意味著從開始請求到第一次接收需求數據之間的時間會比較長,並且不時地必須執行一些冗長的登陸進程。
HTTP協議(HyperText Transfer Protocol,超文本傳輸協議)是用於從Web伺服器傳輸超文本到本地瀏覽器的傳輸協議,其可以使瀏覽器更加高效,使網絡傳輸減少;不僅保證計算機正確快速地傳輸超文本文檔,還確定傳輸文檔中的哪一部分以及哪部分內容首先顯示(如文本先於圖形)等。
具體而言,HTTP是客戶端瀏覽器或其他程序與Web伺服器之間的應用層通信協議。在Internet上的Web伺服器上存放的都是超文本信息,客戶機需要通過HTTP協議傳輸所要訪問的超文本信息。HTTP包含命令和傳輸信息,不僅可用於Web訪問,也可以用於其他網際網路/內聯網應用系統之間的通信,從而實現各類應用資源超文件訪問的集成。
通常,在瀏覽器的地址欄裡輸入的網站地址叫做URL(Uniform Resource Locator,統一資源定位符),就像每家每戶都有一個門牌地址一樣,每個網頁也都有一個Internet地址。當用戶在瀏覽器的地址框中輸入一個URL或是單擊一個超連結時,URL就確定了要瀏覽的網頁地址。瀏覽器通過超文本傳輸協議(HTTP)將Web伺服器上站點的網頁代碼提取出來並翻譯成漂亮的網頁;當然也可以通過超文本傳輸連結地址定位到伺服器端的文件下載點,從而將存儲在伺服器端的媒體文件下載至本地客戶端。
此外,對於用戶自定義非標準的數據傳輸協議,不同的開發者定義的數據傳輸格式和協議可能各不相同,因此文件數據傳輸的可靠性也無法整體去評估。
目前,針對以上現有技術的文件傳輸機制主要存在的問題:1)文件數據傳輸的可靠性不高;2)整體系統設計的冗餘性不好;3)數據傳輸中斷之後需要全部重傳整個文件數據,浪費網絡流量,不能節省資源;以及4)文件數據傳輸的時效性不高,例如數據傳輸中斷導致LED顯示屏黑屏。
技術實現要素:
因此,本發明主要解決現有技術中的缺陷和不足,提供一種文件傳輸方法。
具體地,本發明實施例提出的一種文件傳輸方法,包括步驟:(i)根據待傳輸文件的大小確定所述待傳輸文件的首選傳輸方式;(ii)利用所述首選傳輸方式向外傳輸所述待傳輸文件;以及(iii)當利用所述首選傳輸方式向外傳輸所述待傳輸文件出現異常中斷時,切換至所述待傳輸文件的備選傳輸方式進行所述待傳輸文件的向外傳輸,其中所述首選傳輸方式和所述備選傳輸方式不同且每一者是基於標準協議的文件傳輸方式或基於自定義非標準協議的文件傳輸方式。
在本發明的一個實施例中,所述文件傳輸方法在步驟(iii)之後還包括步驟:當利用所述備選傳輸方式向外傳輸所述待傳輸文件出現異常中斷時,再切換至所述待傳輸文件的第二備選傳輸方式進行所述待傳輸文件的向外傳輸。
在本發明的一個實施例中,所述文件傳輸方法在步驟(ii)之前還包括步驟:將所述待傳輸文件按照預設數據長度進行分包處理並對每包數據進行標記;相應地步驟(iii)包括:將未發送數據包的標記通知所述備選傳輸方式以使所述備選傳輸方式續傳所述待傳輸文件剩餘的文件數據。
在本發明的一個實施例中,所述步驟(i)包括:當所述待傳輸文件的大小位於第一範圍內,確定所述待傳輸文件的首選傳輸方式為基於第一標準協議的文件傳輸方式;當所述待傳輸文件的大小位於第二範圍內,確定所述待傳輸文件的首選傳輸方式為基於第二標準協議的文件傳輸方式;以及當所述待傳輸文件的大小位於第三範圍內,確定所述待傳輸文件的首選傳輸方式為基於自定義非標準協議的文件傳輸方式。
在本發明的一個實施例中,所述第一範圍內的任意值大於所述第二範圍內的任意值,且所述第二範圍內的任意值大於所述第三範圍內的任意值。
在本發明的一個實施例中,當所述待傳輸文件的大小位於所述第一範圍內,步驟(iii)中的所述備選傳輸方式為所述基於第二標準協議的文件傳輸方式;以及當所述待傳輸文件的大小位於所述第二範圍或所述第三範圍內,步驟(iii)中的所述備選傳輸方式為所述基於第一標準協議的文件傳輸方式。
在本發明的一個實施例中,所述文件傳輸方法在步驟(ii)之前還包括步驟:當利用所述備選傳輸方式向外傳輸所述待傳輸文件出現異常中斷時,再自動切換至所述待傳輸文件的第二備選傳輸方式以續傳所述待傳輸文件剩餘的文件數據;當所述待傳輸文件的大小位於所述第一範圍或所述第二範圍內,所述第二備選傳輸方式為所述基於自定義非標準協議的文件傳輸方式;以及當所述待傳輸文件的大小位於所述第三範圍內,所述第二備選傳輸方式為所述基於第二標準協議的文件傳輸方式。
在本發明的一個實施例中,所述基於第一標準協議的文件傳輸方式為基於FTP協議的文件傳輸方式,所述基於第二標準協議的文件傳輸方式為基於HTTP協議的文件傳輸方式,以及所述基於自定義非標準協議的文件傳輸方式為基於UDP廣播和TCP/IP連接的自定義非標準協議的文件傳輸方式。
此外,本發明另一實施例提出的一種文件傳輸方法,包括步驟:將待傳輸文件按照預設數據長度進行分包處理並對每包數據進行標記;將所述待傳輸文件標記後的每包數據以第一文件傳輸方式向外傳輸;以及當利用所述第一文件傳輸方式向外傳輸所述待傳輸文件出現異常中斷時,切換至第二文件傳輸方式並將未發送數據包的標記通知所述第二文件傳輸方式以使所述第二文件傳輸方式續傳所述待傳輸文件剩餘的文件數據;其中所述第一文件傳輸方式和所述第二文件傳輸方式不同。
在本發明的一個實施例中,所述文件傳輸方法還包括步驟:當所述第二文件傳輸方式續傳所述待傳輸文件剩餘的文件數據出現異常中斷時,切換至第三文件傳輸方式續傳所述待傳輸文件在採用第二文件傳輸方式後剩餘的文件數據;其中,所述第三文件傳輸方式為基於UDP廣播和TCP/IP連接的自定義非標準協議的文件傳輸方式,所述第一文件傳輸方式和所述第二文件傳輸方式為基於不同標準協議的文件傳輸方式。
由上可知,本發明實施例可以達成以下一個或多個有益效果:1)增加系統的文件傳輸的可靠性;2)提高系統設計的冗餘度;3)增加文件傳輸的時效性;以及4)降低用戶應用成本。
通過以下參考附圖的詳細說明,本發明的其它方面和特徵變得明顯。但是應當知道,該附圖僅僅為解釋的目的設計,而不是作為本發明的範圍的限定。還應當知道,除非另外指出,不必要依比例繪製附圖,它們僅僅力圖概念地說明此處描述的結構和流程。
附圖說明
下面將結合附圖,對本發明的具體實施方式進行詳細的說明。
圖1為本發明實施例提出的一種交通顯示控制系統架構示意圖。
圖2為本發明實施例提出的一種文件傳輸方案框圖。
圖3為本發明實施例提出的一種採用基於自定義非標準協議的文件傳輸方式進行文件傳輸的流程示意圖。
具體實施方式
為使本發明的上述目的、特徵和優點能夠更加明顯易懂,下面結合附圖對本發明的具體實施方式做詳細的說明。
針對當前的客戶端例如LED控制系統的文件數據傳輸的應用方式可靠性相對較低、時效性不高以及成本相對較高等問題,本發明下述實施例提出一種高可靠性、系統冗餘度高、時效性較好以及成本較低的文件傳輸機制,其既可以節省用戶的成本,也可以增加系統整體的穩定性及可靠性和時效性。
參見圖1,其為本發明實施例提出的一種交通顯示控制系統架構示意圖。如圖1所示,在交通LED控制系統應用行業,伺服器端與LED異步控制卡之間是通過交通專網進行文件數據傳輸交互,這樣安全性相對較高,不易受其他網絡環境下的黑客攻擊幹擾。
然而,在交通顯示控制系統專網環境下,雖然不受外界網絡環境的黑客攻擊幹擾,但是現有技術中採用單獨的數據傳輸協議進行文件傳輸的方式可靠性也是無法得到完全保證的。
請參見圖2,為本發明實施例提出的一種文件傳輸方案框圖。如圖2所示,本發明實施例的文件數據傳輸交互機制是將基於FTP協議文件傳輸方式,基於HTTP協議文件傳輸方式以及基於自定義非標準協議文件傳輸方式結合冗餘實現,並且優選為支持斷點續傳的功能;其在無線3G/4G等無線傳輸系統環境下可以節省用戶的數據使用流量,從而節省產品應用成本。
更具體地,本發明實施例的文件傳輸方案主要是將大文件、中等文件以及小文件作為不同種類的文件以不同的方式進行文件傳輸,而不是所有的文件均採用一種文件傳輸方式,並且在出現大文件傳輸異常中斷的情況下,可以自動切換到中等文件所採用的傳輸方式下續傳剩餘的文件數據,直到文件傳輸結束;在中等文件傳輸如果也出現異常的情況下,會再自動切換到小文件所採用的傳輸方式下續傳剩餘文件數據,直到整個文件傳輸結束,即完成整個文件的傳輸過程。
承上述,本發明實施例定義大文件是大小大於10M的文件,中等文件是大小大於1M且小於或等於10M的文件,而小文件是大小大於0且小於或等於1M的文件。當然,本領域技術人員可以理解的是,此處大文件、中等文件和小文件的大小劃分僅為舉例,並非用來限制本發明。
再者,本發明實施例主要用於大文件傳輸的是基於FTP協議的文件傳輸方式,用於中等文件傳輸的是基於HTTP協議的文件傳輸方式,而用於小文件傳輸的是基於UDP廣播和TCP/IP連接的自定義非標準協議的文件傳輸方式;以上三種文件傳輸協議之間可以相互切換續傳。在系統檢測到某個出現異常的客戶端不傳輸時,會自動切換至通過另外一個文件傳輸方式進行文件數據續傳。
另外,本發明實施例在採用三種不同的文件傳輸方式時,會先對文件進行分包處理,例如將文件數據按照例如256位元組(Bytes)長度進行一次分包,進行數據分包處理之後對得到的每包數據進行標記得到包的標記位,然後再將標記後的每包數據按照指定的文件傳輸方式進行文件發送。
三種文件傳輸方式之間的異常中斷自動切換方式例如為:
a)若首先採用基於FTP協議的文件傳輸方式出現異常中斷時,自動切換至基於HTTP協議的文件傳輸方式,如果切換後的基於HTTP協議的文件傳輸方式也出現異常,會再自動切換至基於自定義非標準協議的文件傳輸方式;
b)首先採用基於HTTP協議的文件傳輸方式出現異常中斷時,自動切換至基於FTP協議的文件傳輸方式,如果切換後的基於FTP協議的文件傳輸方式也出現異常,會再切換至自定義非標準協議的文件傳輸方式;以及
c)若首先採用基於自定義非標準協議的文件傳輸方式出現異常中斷時,自動切換至基於FTP協議的文件傳輸方式,如果切換後的基於FTP協議的文件傳輸方式再出現異常,會再自動切換至基於HTTP協議的文件傳輸方式。
此外,三種文件傳輸方式在出現異常中斷時,優選為將未發送的數據包標記通知到切換後的文件傳輸方式,並從此包數據開始續傳剩餘的文件數據。
參見圖3,其本發明實施例提出的一種採用基於自定義非標準協議的文件傳輸方式進行文件傳輸的流程示意圖。具體地,本實施例的基於自定義非標準協議的文件傳輸方式是在伺服器端發起文件傳輸之後進行的一種文件自定義傳輸流程。在伺服器端發起文件傳輸之後(例如由用戶觸發),伺服器端會先通過UDP廣播詢問是否有客戶端例如LED異步控制卡在線,如果沒有客戶端在線的話,就終止發送並提示伺服器端用戶當前暫無客戶端在線,如果有收到某些客戶端回復的話,就對要傳輸的文件先進行MD5校驗處理(當然並不限於MD5校驗,也可以是其它基於文件內容的指紋校驗算法),並將生成的校驗文件在最後一包數據發送完之後發送給客戶端以用於客戶端對接收到的文件的完整性和正確性進行校驗(例如MD5校驗)。在對文件數據完成校驗以後,將文件數據每包例如按照256位元組進行分包處理,並對分包後的每包數據例如按照順序編號進行標記,分包處理結束以後,對每包數據加包頭包尾及校驗位、包的標記位(例如對應順序編號)、數據總長度和包的總數以完成封包處理,封包處理以後將每包數據通過TCP/IP網絡連接發送至客戶端。客戶端對接收到的數據包進行解包及數據組包處理以及最終的校驗等操作,最終如果校驗後的文件數據不正常(例如MD5校驗失敗),則返回錯誤信息給伺服器端告知其數據傳輸錯誤並請求重傳等操作;反之如果最終校驗文件數據正常,則文件傳輸結束,返回成功信息給到伺服器端。
綜上所述,本發明前述實施例針對不同文件大小,採用不同傳輸方式能夠快速有效的實現文件的可靠性傳輸,減小小文件傳輸採用複雜協議傳輸的時效性較差的問題。此外,本發明實施例的三種文件傳輸方式之間相互切換續傳的方式也增加了整個系統文件傳輸的可靠性,並且續傳功能還降低了網絡流量浪費的問題。因此,本發明可以達成以下一個或多個有益效果:1)增加系統的文件傳輸的可靠性;2)提高系統設計的冗餘度;3)增加文件傳輸的時效性;以及4)降低用戶應用成本。
最後,值得一提的是,本發明實施例並不限於將待傳輸的文件根據其大小劃分成三種類型,也可以按照文件大小劃分成兩種類型甚至更多類型並為各種類型的文件指定不同的首選傳輸方式。此外,在其它實施例中,也可以不區分文件大小且指定文件的首選傳輸方式優選為基於FTP協議的文件傳輸方式、且當首選傳輸方式出現異常中斷傳輸時自動切換至備選傳輸方式;並且優選地,將未發送的數據包標記通知到自動切換後的備選傳輸方式以供備選傳輸方式從此包數據開始續傳剩餘的文件數據。
以上所述,僅是本發明的較佳實施例而已,並非對本發明作任何形式上的限制,雖然本發明已以較佳實施例揭露如上,然而並非用以限定本發明,任何熟悉本專業的技術人員,在不脫離本發明技術方案範圍內,當可利用上述揭示的技術內容做出些許更動或修飾為等同變化的等效實施例,但凡是未脫離本發明技術方案內容,依據本發明的技術實質對以上實施例所作的任何簡單修改、等同變化與修飾,均仍屬於本發明技術方案的範圍內。