文件傳輸協(xié)議范文

時間:2023-03-26 18:49:55

導語:如何才能寫好一篇文件傳輸協(xié)議,這就需要搜集整理更多的資料和文獻,歡迎閱讀由公務員之家整理的十篇范文,供你借鑒。

文件傳輸協(xié)議

篇1

1延遲NAK模式

在CFDP中,文件傳輸被稱為一個“事務”,發(fā)送端為每一個文件傳輸操作分配了一個事務ID號。事務ID號與源ID和其他信息一起包含在每一個PDU的報頭里。發(fā)送端通過發(fā)送元數(shù)據(jù)PDU來通知接收端文件傳輸?shù)拈_始。發(fā)送端不必等待接收端的ACK應答才開始文件PDUs的傳輸,也就是說,在初始化“事務”時沒有握手過程[9]。在延遲NAK模式中,接收端直到正確收到發(fā)送端的EOFPDU后才發(fā)出NAKs重傳請求。在此過程中接收端統(tǒng)計直至EOFPDU成功接收時所有丟失的PDUs。在收到EOFPDU后,接收端發(fā)出ACK(EOF)并發(fā)出一個包含所有丟失PDUs的重傳請求NAK(如果需要的話)。一旦收到一個NAK,發(fā)送端立即重傳NAK所要求的PDUs。在接收端發(fā)出NAK后,立即啟動一個定時器,當NAK定時器溢出時,接收端再次檢查丟失PDUs的記錄。如果仍有未收到的PDUs,接收端發(fā)出另一個NAK并再次啟動一個定時器。這種過程一直持續(xù)到所有PDUs都被成功接收,包含全部的文件內(nèi)容PDUs和元數(shù)據(jù)PDU。在收到所有的PDUs后,接收端發(fā)出一個FINPDU,且發(fā)送端一旦收到FINPDU就回復一個ACK(FIN),并關閉事務。接收端在成功接收ACK(FIN)后也隨之關閉事務[10]。

2平均文件傳輸時間的數(shù)學分析

首先定義“文件傳輸時間”為從元數(shù)據(jù)PDU的第一比特開始直到當所有文件數(shù)據(jù)、元數(shù)據(jù)和EOFPDU被接收端成功接收的時刻?!癊OF傳輸時間”定義為發(fā)送端發(fā)送最后一個文件數(shù)據(jù)PDU后的時刻與接收端接收到無錯誤的EOFPDU的最后一比特時刻間的時間間隔,“NAK重傳時間”定義為從接收端發(fā)出第一個NAK的第一比特開始到所有重傳的PDUs被成功接收到的時刻為止,如圖1所示,其次定義N為攜帶文件數(shù)據(jù)的PDUs加上一個元數(shù)據(jù)PDU的總和??梢姡麄€文件的傳輸時間包含四部分:單向傳播時間、N個文件PDU的傳輸時間、EOF傳輸時間和NAK重傳時間。為了分析方便,假設如下:第一,N個PDUs等長、具有相同的傳輸時間且發(fā)送失敗概率相等;第二,所有的重傳NAKs等長且具有相同的發(fā)送失敗概率(雖然NAK的長度取決于所要求重傳PDU的個數(shù),但是這種差異很小且NAKs的長度很小,所以這種假設對性能影響很小);第三,在前向和反向鏈路中的PDU錯誤事件是統(tǒng)計獨立的;第四,由于EOF,ACK(EOF)和NAK的長度相對于文件數(shù)據(jù)PDUs來說很小,所以忽略這些PDUs的傳輸時間。文中分析用到的記號規(guī)定見表1。由于深空探測器具有功率有限及傳輸帶寬極其嚴格的特點,為了保證鏈路最大吞吐率,應該盡量避免同一PDU不必要的復制重傳。在此限定條件下,EOF定時器的最小設定值為2Tprop,NAK定時器的最小設定值為2Tprop+RTi,其中RTi表示第i次NAK重傳請求PDU的發(fā)送時間。現(xiàn)在重點考慮重傳階段,定義隨機變量Hi為第i個PDU直到接收端成功接收所需的重傳次數(shù)。在這種假設條件下,Hi具有幾何分布特性。再定義一個隨機變量HM表示直至所有PDU成功被接收端接收所需的重傳次數(shù),易知,HM=max{H1,H2,H3,…,HN}。

3性能仿真與結果分析

利用Matlab工具進行仿真分析,傳輸時間單位為天文單位a.u.(astronomicalunit,1a.u.=480s)。圖2~圖4仿真出平均文件傳輸時間隨PDU錯誤概率、PDU數(shù)目、單向傳播時間等不同條件下的變化情況。由圖2可知,在單向傳播時間及PDU數(shù)目確定的情況下,單個PDU傳輸時間越多,在相同PDU錯誤概率情況下所需的傳輸時間越多。由圖3不難看出,在PDU錯誤概率及單向傳播時間固定的條件下,平均文件傳輸時間隨PDU數(shù)目的增加而不斷增加,且單個PDU傳輸時間越多,在相同PDU數(shù)目的情況下所需的傳輸時間越多。由圖4易知,在PDU錯誤概率及單個PDU傳輸時間固定的情況下,平均文件傳輸時間隨單向傳播時間及PDU數(shù)目的增加而不斷增加。圖5為平均文件傳輸時間對PDU錯誤概率的Montecarlo仿真與數(shù)值分析曲線。可以看出,仿真曲線與數(shù)值分析曲線非常匹配。這里,PDU錯誤概率為0.01~0.5,單向傳播時間為1a.u.,雙向傳輸速率為20kbps,PDU數(shù)目為1000,且單個PDU傳輸時間為0.8s(PDU長度2KB,文件大小2MB)。

篇2

調(diào)試也是軟件開發(fā)不可或缺的一個環(huán)節(jié)。在常見軟件開發(fā)中,調(diào)試器與被調(diào)試的程序往往運行在同一臺機器上,通過操作系統(tǒng)的調(diào)試接口來控制被調(diào)試的進程。而在嵌入式軟件開發(fā)中,采用的是交叉調(diào)試,即調(diào)試器運行在宿主機上,但被調(diào)試的程序運行在基于特定平臺的目標機上,調(diào)試器與被調(diào)試進程通過串口或網(wǎng)絡進行通信。不管是交叉編譯還是交叉調(diào)試,都需要把文件從宿主機傳送到目標機。如果考慮團隊合作開發(fā)、開發(fā)環(huán)境不完全一致等因素,開發(fā)者經(jīng)常也需要把文件在不同系統(tǒng)之間或通過網(wǎng)絡進行傳輸。所以在嵌入式軟件開發(fā)中搭建一個良好的文件傳輸環(huán)境是提高嵌入式軟件開發(fā)效率的一個關鍵因素。

2文件傳輸環(huán)境的搭建

在嵌入式軟件開發(fā)中,必須結合開發(fā)的具體項目和具體開發(fā)環(huán)境來選擇搭建一個好的文件傳輸系統(tǒng)。雖然各類傳輸技術可以在不同平臺(Windows、Linux等)上實現(xiàn),但在嵌入式軟件開發(fā)中更適合搭建基于Linux的文件傳輸系統(tǒng),下面就嵌入式Linux環(huán)境下文件傳輸技術方法進行討論。

2.1FTP(文件傳輸協(xié)議)服務設計與實現(xiàn)

FTP是網(wǎng)絡傳輸文件的一種常見服務。在嵌入式Linux中,vsftpd是一款在Linux發(fā)行版中最受推崇的FTP服務器程序,是一款完全免費的軟件。它的最大的特點是安全性非常高,但嵌入式系統(tǒng)一般是在局域網(wǎng)內(nèi)進行合作開發(fā),所以在搭建為嵌入式開發(fā)服務的FTP時一般不需要太多地考慮文件傳輸?shù)陌踩?,搭建一個用戶登錄訪問的FTP服務器就可以。下文是Ubuntu12.04下實現(xiàn)用戶登錄訪問FTP配置文件(/etc/vs-ftpd.conf)的主要內(nèi)容:

2.2TFTP(簡單文件傳輸協(xié)議)服務設計與實現(xiàn)

TFTP是一個傳輸文件的簡單協(xié)議,它基于UDP協(xié)議而實現(xiàn),適合于小文件傳輸。嵌入式系統(tǒng)開發(fā)的代碼文件一般不會很大,同時對文件傳輸?shù)陌踩砸笠膊桓?,所以在嵌入式軟件開發(fā)中也經(jīng)常使用TFTP服務來傳輸文件。下文是Ubuntu12.04下實現(xiàn)TFTP配置文件(/etc/default/tftpd-hpa)的主要內(nèi)容:2.3NFS(網(wǎng)絡文件系統(tǒng))服務設計與實現(xiàn)嵌入式系統(tǒng)開發(fā)時,還可以使用NFS實現(xiàn)宿主機和開發(fā)板共享文件,這樣也可以免去文件上傳或下載的麻煩,直接把存放文件的目錄掛載在目標機上或其他系統(tǒng)中,用戶可以像訪問本地文件一樣訪問遠端系統(tǒng)上的文件。下文是Ubuntu12.04下實現(xiàn)NFS配置文件(/etc/exports)的主要內(nèi)容:其中,*:允許所有的網(wǎng)段訪問,也可以設置成某一個ip段,如192.168.0.*;rw:讀寫權限;sync:資料同步寫入內(nèi)存和硬盤;no_root_squash:允許客戶端共享目錄所有者權限。用戶可以根據(jù)自己需要設置相關參數(shù),還有一些參數(shù)說明沒列出來,需要時可查閱相關資料。

2.4Samba服務設計與實現(xiàn)

在嵌入式系統(tǒng)開發(fā)過程中,宿主機上一般會安裝Windows系統(tǒng),同時安裝虛擬機軟件,在虛擬機上安裝Linux,這樣就存在Windows系統(tǒng)和Linux系統(tǒng)共享文件的問題。通過Linux提供的Samba服務可以輕松實現(xiàn)文件共享,可以有兩種方法加以實現(xiàn):一是由Windows系統(tǒng)訪問Linux系統(tǒng)中的共享文件夾;二是由Linux系統(tǒng)訪問Windows系統(tǒng)中的共享文件夾。(1)Windows系統(tǒng)訪問Linux系統(tǒng)中的共享文件夾。由于嵌入式系統(tǒng)開發(fā)一般在局域網(wǎng)內(nèi)或單機上進行,對網(wǎng)絡安全性要求不高,這里就以配置一最易實現(xiàn)的Samba服務(來賓都可訪問)為例來加以說明。主要是通過修改/etc/samba/smb.conf配置文件:上面用戶名是所訪問的Windows計算機中的用戶賬戶,驗證口令是Windows計算機中的用戶賬戶的口令。

2.5使用串口軟件傳輸文件

在一些應急場合,沒能很好地配置好上述服務的情況下,如果需要傳輸一些文件到目標板,可以選擇使用串口軟件傳輸文件。用串口電纜把宿主機和目標機連好,然后運行串口軟件,最常用的是Windows自帶的超級終端。超級終端程序通常位于“開始”“程序”“附件”“通訊”中,運行超級終端一般要求用戶為新的連接取一個名字,然后選擇所使用的串口,最重要的一步是設置串口屬性,一般針對開發(fā)板設置的屬性如下圖2所示。連接上目標板后,使用超級終端上的“傳送”“傳送文件”菜單實現(xiàn)文件傳輸。在ubuntu操作系統(tǒng)下,需要使用minicom來連接開發(fā)板,本文不再贅述。

3結束語

篇3

軟件使用技巧:1、在手機迅雷6.06.2版本中可以設置同時下載任務數(shù),打開軟件,進入個人主頁,點擊設置圖標,點擊下載設置,選擇“同時下載任務數(shù)”,根據(jù)需要設置即可。

2、在手機迅雷6.06.2版本中,軟件會自動檢測下載鏈接,復制下載鏈接后,直接點擊“立即下載”即可。

3、軟件可以選擇下載存儲路徑,打開軟件,進入個人主頁,點擊“選擇存儲路徑”,可以設置為外部存儲。

4、在手機迅雷6.06.2版本中,可以使用“邊下載邊看”功能。

5、軟件無法使用,可能是需要升級。

篇4

關鍵詞 Teradata數(shù)據(jù)倉庫;ETL;模型設計;流程實施

中圖分類號TP392 文獻標識碼A 文章編號 1674-6708(2014)111-0208-02

電信行業(yè)領導決策者要想第一時間得到競爭對手行業(yè)的實際情況,就必須在企業(yè)中構建匹配的體系結構,以對多樣化格式與形式的外部數(shù)據(jù)加以全面收集。ETL是數(shù)據(jù)加載至數(shù)據(jù)倉庫必不可少的一個重要流程,該流程的科學合理與否對數(shù)據(jù)倉庫接收數(shù)據(jù)質(zhì)量的高低起到了決定性的作用。盡管我國在ETL方面的研究取得了較好的效果,但是目前還缺乏統(tǒng)一的ETL 設計模型,所進行的ETL模型的設計與開發(fā)僅僅圍繞了各電信行業(yè)系統(tǒng)特點而實施的,只可以在此系統(tǒng)環(huán)境下有效運行,具有一定的局限性。

1 Teradata數(shù)據(jù)倉庫的ETL模型設計

1.1結合電信行業(yè)特征,對ETL框架進行設計

具體設計ETL 模型過程中,必須對此模型涉及的應用領域特點予以全面的了解,結合實況構建相應的模型。切實根據(jù)電信行業(yè)ETL 框架的流程特性,首先對數(shù)據(jù)進行合理的轉(zhuǎn)換,接下來獲取相應的數(shù)據(jù),最后等待數(shù)據(jù)成功下載,使用這樣的步驟流程,與電信行業(yè)中實行的ETL 流程結構相符。具體的設計步驟是:首先,所有類型的業(yè)務平臺的源數(shù)據(jù)實際都會按照具體的抽取規(guī)范標準來抽取,在形成一個統(tǒng)一的文件格式后,具體儲存于要求的FTP 服務器目錄中;其次,開啟FTP 調(diào)度進程,及時有效轉(zhuǎn)換儲存于要求的文件傳輸協(xié)議(FTP )中的接口文件,除此之外,還要通過文件傳輸協(xié)議(FTP)將接口文件傳送至數(shù)據(jù)的抽取、清洗、轉(zhuǎn)換、裝載(ETL服務器)規(guī)定的目錄中,此目錄屬于一種分發(fā)目錄,接口文件經(jīng)過一番轉(zhuǎn)換后會變成一體化的 AVL/ CHK 格式。實際當接口文件進入到數(shù)據(jù)的抽取、清洗、轉(zhuǎn)換、裝載(ETL 服務器)后,這個時候系統(tǒng)會啟動某一數(shù)據(jù)分發(fā)的調(diào)度進程,以此準確及時的分發(fā)ETL 服務器內(nèi)的所有接口文件,讓其進入到其它的加載目錄中,在接口文件送至加載目錄中之后,ETL Automat on 會將一個裝載進程全面開啟,把存于此目錄中的接口文件加載到數(shù)據(jù)倉庫中。這與電信行業(yè)下的ETL 框架流程特征相一致。

1.2傳統(tǒng)行業(yè)中的ETL 框架

以往中,行業(yè)實施的ETL設計流程太過簡單化。常常在一臺服務器上實施全部ETL 流程,實施的順序是:先抽取源數(shù)據(jù),把實際抽取的數(shù)據(jù)做數(shù)據(jù)加載,產(chǎn)生臨時表1,然后將臨時表1中的數(shù)據(jù)予以一番清洗,產(chǎn)生臨時表2,最后把臨時表2中的數(shù)據(jù)進行轉(zhuǎn)換,再加載至數(shù)據(jù)倉庫中。

1.3電信行業(yè)和傳統(tǒng)行業(yè)ETL比較

在電信行業(yè)特的ETL 框架模型的優(yōu)勢具體體現(xiàn)在:首先,根據(jù)所有平臺中需進行加載的數(shù)據(jù)有著統(tǒng)一格式的文件形式,保證了調(diào)度抽取的統(tǒng)一性。其次,在接口文件還沒加載到數(shù)據(jù)倉庫前,將其劃分成了抽取、分發(fā)、加載這幾個流程步驟。由于這三個流程步驟有著各自的控制程序,所以,能夠?qū)φw的ETL過程一目了然,而且還能夠及時發(fā)現(xiàn)存在的問題并采取有效措施加以改進與準確定位。最后,把所有的ETL 機制放置于各服務器中來調(diào)度處理,使得諸多的原本繁瑣的步驟實現(xiàn)了流程化,對所有中間環(huán)節(jié)均一目了然。

2 Teradata數(shù)據(jù)倉庫的ETL具體實施流程

2.1 ETL Automat on 的無故障處理機制

1)抽取、轉(zhuǎn)換接口文件;將各業(yè)務平臺中的接口文件放置于各類FTP的服務器目錄中,各接口文件在抽取結束后,凡是其涉及的數(shù)據(jù)信息都要通過兩種不同后綴名的文件來表示,比如,* . AVL、* . CHK。* . AVL文件對此接口文件中涉及的全部信息進行了詳細的記錄,但* . CHK文件僅僅記錄下了* . AVL內(nèi)的數(shù)據(jù)條數(shù)和數(shù)據(jù)大小情況,主要是檢查數(shù)據(jù)信息是否是精確無誤的,這樣有利于保證ETL 分發(fā)加載流程循序漸進發(fā)展。在ETL Automat on 機制中,從數(shù)據(jù)源內(nèi)抽取的數(shù)據(jù)具有命令的腳本Interface_Extract . Pl會把源系統(tǒng)服務器中滿足抽取要求的接口文件提取出來,放入文件傳輸協(xié)議(FTP )服務器目錄中,在對接口文件提取時,會先將文件傳輸協(xié)議(FTP) 服務器IP 和用戶名及密碼與相配套的源系統(tǒng)服務器全部綜合在一起,然后在接口文件的基礎上對配置表InterfaceF leconf g進行合理提取,再把與抽取規(guī)則相符的接口文件通過二進制傳輸模式抽取到FTP 服務器內(nèi)一些匹配的目錄中,同時在抽取完所有接口文件后,系統(tǒng)會及時把此接口文件最后產(chǎn)生的抽取結果詳細的記錄在一個接口文件抽取日志表,即Interface F le Extract log中;

2)ETL Automat on 機制中接口文件的分發(fā);系統(tǒng)將接口分發(fā)進程全面開啟,這種進程主要職責是分發(fā)和調(diào)度實際已轉(zhuǎn)換好的. AVL 和. CHK 的接口文件。在此進程中主要圍繞接口文件分發(fā)配置表InterfaceF leconf g 對ETL 服務器中分發(fā)目錄內(nèi)的接口文件進行掃描,若發(fā)現(xiàn)了滿足于相關提取要求的接口文件,程序會及時按照. CHK 文件對此接口文件需不需要分發(fā)操作進行準確判斷,同時在數(shù)據(jù)倉庫中的兩張表中分別登記分發(fā)記錄、分發(fā)狀態(tài)。所有接口文件不管分發(fā)成功還是分發(fā)失敗,系統(tǒng)都會把具體的分發(fā)狀態(tài)輸送至分發(fā)日志In terface D spatch log中。在結束分發(fā)操作后,會將接口文件移送至ETL 服務器內(nèi)的裝載目錄中,進行裝載。將此分發(fā)環(huán)節(jié)添入到ETL Automat on 機制中的主要目的是使數(shù)據(jù)裝載到數(shù)據(jù)倉庫后數(shù)據(jù)具有較高的質(zhì)量。具備數(shù)據(jù)分發(fā)環(huán)節(jié)后,能夠及時的獲悉存在的問題,從而采取措施及時處理。

2.2 ETL Automat on 的異常處理機制

從ETL 流程角度上分析,因源系統(tǒng)或者ETL 流程自身問題的存在,運行中往往會引起ETL 過程的中斷。對于這種情況,應做好異常處理,此中斷現(xiàn)象在ETL任何環(huán)節(jié)中都會發(fā)生。在檢查處理整個ETL 流程環(huán)節(jié)時,應從以下幾方面進行:首先,結合ETL 狀態(tài)記錄表的信息獲悉出現(xiàn)問題的環(huán)節(jié)。其次,按照具體定位的某一環(huán)節(jié),及時收集記錄此環(huán)節(jié)的系統(tǒng)詳細日志,并定位找出導致此類問題發(fā)生的主要原因。

3結論

綜上所述可知,設計了一臺與電信行業(yè)特點相一致的ETL 模型, 此模型能夠把之前較為復雜的ETL劃分為諸多的較為獨立的處理單元,對ETL 過程一目了然。同時,把本來要在數(shù)據(jù)倉庫中實施的所有數(shù)據(jù)操作步驟全部拆分,通過多臺服務器來相應操作,減輕了數(shù)據(jù)倉庫的壓力,推動了數(shù)據(jù)倉庫的有效執(zhí)行,數(shù)據(jù)得到及時傳輸。

篇5

網(wǎng)絡編程基于TCP協(xié)議的網(wǎng)絡編程,按照是否有幀聽端口,通常分為兩種模式,一種是服務器模式(偵聽端口),另外一種為客戶端模式。本儀器采用的是客戶端模式。關于Linux網(wǎng)絡通信中客戶端編程的初始化代碼,由于資料較多,這里不再累述。本文僅僅給出接收數(shù)據(jù)或發(fā)送數(shù)據(jù)的部分代碼,因為儀器除了要處理網(wǎng)絡信息外,還要進行檢測數(shù)據(jù)的采集以及按鍵信息的處理,因此網(wǎng)絡數(shù)據(jù)的傳送或接收,不可以是阻塞的模式,必須是能夠立即返回的非阻塞模式。本儀器采用傳統(tǒng)的Linux操作系統(tǒng)下API函數(shù)select,來實現(xiàn)對網(wǎng)絡端口狀態(tài)的監(jiān)控,進而實現(xiàn)數(shù)據(jù)傳輸?shù)姆亲枞δ堋R韵率菍崿F(xiàn)功能的部分代碼。發(fā)送數(shù)據(jù)的代碼段,其中m_tv變量保存的是超時返回的時間設置。接收數(shù)據(jù)的代碼段,m_tv的定義同上。如檢測到網(wǎng)絡口有數(shù)據(jù)上送的時候才進行數(shù)據(jù)的接收。

通信模塊的詳細介紹

通信協(xié)議介紹發(fā)生通信的兩端(儀器和上位機),按照事先對數(shù)據(jù)傳送的同步方式、數(shù)據(jù)結構、底層通信協(xié)議進行相互的約定,共同的遵守,這些約定就稱為通信規(guī)約?;诰W(wǎng)絡接口的通信協(xié)議工作在應用層。通信協(xié)議制定的好壞直接影響儀器傳輸數(shù)據(jù)的速率,以及通信質(zhì)量的可靠程度。按照通信協(xié)議的傳輸類型一般分為三類:(1)循環(huán)上送類型。儀器在進行正常的設置之后,不經(jīng)過上位機的干預,主動將數(shù)據(jù)發(fā)送到上位機。(2)事件驅(qū)動類型。在正常工作模式下不向上位機發(fā)送數(shù)據(jù),當有特殊事件發(fā)生的時候才向上位機發(fā)送數(shù)據(jù)。(3)被動召調(diào)類型。正常工作的時候,儀器不向上位機傳送數(shù)據(jù),直到上位機向儀器發(fā)送召調(diào)報文的時候才進行數(shù)據(jù)上送??紤]到儀器的工作模式,需要實時的向上位機發(fā)送數(shù)據(jù),所以排除事件驅(qū)動類型的通信規(guī)約。由于檢測手段的限制,要求儀器軟件采樣率較高,通常為10kHz以上,故對于數(shù)據(jù)傳輸?shù)膶崟r性要求較高,也不采用召調(diào)類型的傳輸協(xié)議。最終,儀器采用的是循環(huán)上送類型傳輸協(xié)議。協(xié)議內(nèi)容儀器與上位機進行通信,包括兩個方面的內(nèi)容:(1)從上位機接收報文,例如開始采集數(shù)據(jù)、停止采集、發(fā)送參數(shù)等;(2)將采集到的數(shù)據(jù)發(fā)送給上位機,以供上位機進行顯示或分析。的是三組0xD70x09共6個字節(jié)作為同步字,該報文頭參照“部頒CDT循環(huán)遠動規(guī)約”中的報文規(guī)定。數(shù)據(jù)幀長度:表示該幀報文的長度,由兩個字節(jié)的長度表示,低字節(jié)在前,高字節(jié)在后。報文的長度不包括同步字的六個字節(jié)。命令控制字:指示該幀報文的作用,由兩個字節(jié)的長度表示,低字節(jié)在前,高字節(jié)在后。數(shù)據(jù)區(qū)域:包含需要上傳或是下載數(shù)據(jù)的內(nèi)容。數(shù)據(jù)的內(nèi)容都是兩個字節(jié)組成一個數(shù)據(jù)元素,低字節(jié)在前,高字節(jié)在后。在原協(xié)議中,在數(shù)據(jù)區(qū)域后還存在一個校驗碼域,是用來檢驗該幀報文的數(shù)據(jù)是否完整。但由于儀器的底層采用的是基于流套接字的TCP報文協(xié)議,是可靠性連接,并且考慮到數(shù)據(jù)傳送的實時性,在實際的工程使用中將校驗碼域進行刪除。因篇幅有限,僅給出部分實際報文例子,其他報文類似推導即可:(1)開始采集數(shù)據(jù)0xD70x090xD70x090xD70x090x040x000x010x00(2)發(fā)送心跳包0xD70x090xD70x090xD70x090x040x000x050x00(3)循環(huán)上送數(shù)據(jù)0xD70x090xD70x090xD70x090x140x000x080x000x110x000x220x000x330x000x440x000x550x000x660x000x770x000x880x00其中,0x110x00~0x880x00表示的是八個物理采樣通道的檢測數(shù)值。協(xié)議分析流程圖任何數(shù)據(jù)通信協(xié)議都必須依靠軟件實現(xiàn),因此軟件對通信協(xié)議實現(xiàn)的好壞情況,直接影響儀器的系統(tǒng)穩(wěn)定性和其他性能指標。系統(tǒng)的穩(wěn)定性是指儀器能否經(jīng)受得住長時間,大數(shù)據(jù)量傳輸?shù)目简灦怀霈F(xiàn)死機或數(shù)據(jù)傳輸不穩(wěn)定的情況。其他性能指標是指實時性以及均勻性,實時性指儀器能否將數(shù)據(jù)實時的傳輸給上位機或?qū)τ谏衔粰C給出的報警信息是否及時響應,均勻性指數(shù)據(jù)的傳輸是否節(jié)奏一致,不能時快時慢。詳細的程序處理流程協(xié)議分析流程圖。當協(xié)議解析程序段分析出上位機給出的命令控制字后,就可以很方便地根據(jù)命令來進行相關的動作,例如設置參數(shù)、應答數(shù)據(jù)、設置報警等。

儀器軟件自動更新的實現(xiàn)

篇6

由于多種協(xié)議的并存,同時也使網(wǎng)絡變得越來越復雜,而且,廠商之間的網(wǎng)絡設備大部分都不能兼容,很難進行通信。為了解決網(wǎng)絡之間的兼容性問題,幫助各個廠商生產(chǎn)出可兼容的網(wǎng)絡設備,國際標準化組織ISO與1984年提出了OSI RM (Open System Interconnection Reference Model,開放系統(tǒng)互連參考模型)。OSI 參考模型很快成為計算機網(wǎng)絡通信的基礎模型。因此,在設計OSI參考模型時,主要遵循了以下幾點原則:

1.各個層之間有清晰的邊界,便于理解;

2.每層實現(xiàn)特定功能;

3.層次的劃分有利于國際標準協(xié)議的制定;

4 層的數(shù)目應該足夠多,以避免個層功能的重復;

OSI參考模型主要劃分為七層:

1.物理層(physical Layer)

2.數(shù)據(jù)鏈路層(Data Link Layer)

3.網(wǎng)絡層(Network Layer)

4.傳輸層(Transport Layer)

5.會話層(Session Layer)

6.表示層(Presentation Layer)

7.應用層(Application Layer)

下圖是OSI七層模型示意圖

OSI模型的劃分也是為了使網(wǎng)絡的不同功能模塊(不同層次)分擔起不同的職責,具有以下優(yōu)點:

1.簡化了相關的網(wǎng)絡操作

2.在各層分別定義標準接口,使具備相同對等層的不同網(wǎng)絡設備能實現(xiàn)互操作,各層之間則相對獨立,一種高層協(xié)議可放在多種低層協(xié)議上運行;

3.減輕問題的復雜程度,一旦網(wǎng)絡發(fā)生故障,可迅速定位故障所處層次,便于查找和糾錯;

4.防止一個區(qū)域網(wǎng)絡的變化影響另一個區(qū)域的網(wǎng)絡,因此,每一個區(qū)域的網(wǎng)絡都能單獨快速升級。

5.能有效刺激網(wǎng)絡技術革新,因為每次更新都可以在小范圍內(nèi)進行,不需對整個網(wǎng)絡動大手術;

6.便于研究和教學。

下面主要介紹OSI模型各層的定義和功能:

物理層

Physical Layer,是OSI參考模型的最低層或第一層。該層包括物理連網(wǎng)媒介,如電纜連線連接器。物理層的協(xié)議產(chǎn)生并檢測電壓以便發(fā)送和接收攜帶數(shù)據(jù)的信號。在你的PC上插入網(wǎng)絡接口卡,你就建立了計算機連網(wǎng)的基礎。換言之,你提供了一個物理層。盡管物理層不提供糾錯服務,但它能夠設定數(shù)據(jù)傳輸速率并監(jiān)測數(shù)據(jù)出錯率。網(wǎng)絡物理問題,如電線斷開,將影響物理層。

Xerox公司制定的以太網(wǎng)和IEEE802.3標準定義了以太網(wǎng)物理層常用的線纜標準。其中常用的接口線標準有:10Base-T 100Base-T 100Base-TX/FX 1000Base-T 1000Base-SX/LX

物理層常用的設備有中繼器,集線器,路由器,終端主機等,數(shù)據(jù)信號傳輸介質(zhì)主要有同軸電纜,雙絞線,光纖,無線等。

數(shù)據(jù)鏈路層

Datalink Layer,OSI參考模型的第二層,它控制網(wǎng)絡層與物理層之間的通信。[3]它的主要功能是如何在不可靠的物理線路上進行數(shù)據(jù)的可靠傳遞。為了保證傳輸,從網(wǎng)絡層接收到的數(shù)據(jù)被分割成特定的可被物理層傳輸?shù)膸怯脕硪苿訑?shù)據(jù)的結構包,它不僅包括原始數(shù)據(jù),還包括發(fā)送方和接收方的物理地址以及檢錯和控制信息。其中的地址確定了幀將發(fā)送到何處,而糾錯和控制信息則確保幀無差錯到達。 如果在傳送數(shù)據(jù)時,接收點檢測到所傳數(shù)據(jù)中有差錯,就要通知發(fā)送方重發(fā)這一幀。

數(shù)據(jù)鏈路層分為兩個子層:邏輯鏈路控制子層(LLC,Logic Link Control),介質(zhì)訪問控制子層(MAC,Media Access Control)

邏輯鏈路控制子層提供面向連接與面向無連接的網(wǎng)絡服務環(huán)境的需要。該層用于管理通過單一鏈路連接的兩個系統(tǒng)間的通訊,它允許多個高層網(wǎng)絡協(xié)議共享一條鏈路。

LLC子層位于網(wǎng)絡層和MAC子層之間,是上層和下層的管理層,負責流量控制,同步等。LLC子層通過SSAP和DSAP負責底層協(xié)議與網(wǎng)絡層協(xié)議的通信。

MAC子層負責把物理層的0,1 比特流組建成幀,并且通過幀尾部的CRC字段進行錯誤檢測??傊?,MAC子層定義了網(wǎng)絡對共享介質(zhì)的訪問。

數(shù)據(jù)鏈路層協(xié)議的代表包括:SDLC、HDLC、PPP、STP、幀中繼等

網(wǎng)絡層

Network Layer,OSI參考模型的第三層。[4]其主要功能是將網(wǎng)絡地址翻譯成對應的物理地址,并決定如何將數(shù)據(jù)從發(fā)送方路由到接收方。

網(wǎng)絡層通過綜合考慮發(fā)送優(yōu)先權、網(wǎng)絡擁塞程度、服務質(zhì)量以及可選路由的花費來決定從一個網(wǎng)絡中節(jié)點A 到另一個網(wǎng)絡中節(jié)點B 的最佳路徑。由于網(wǎng)絡層處理,并智能指導數(shù)據(jù)傳送,路由器連接網(wǎng)絡各段,所以路由器屬于網(wǎng)絡層。在網(wǎng)絡中,"路由"是基于編址方案、使用模式以及可達性來指引數(shù)據(jù)的發(fā)送。

網(wǎng)絡層負責在源機器和目標機器之間建立它們所使用的路由。這一層本身沒有任何錯誤檢測和修正機制,因此,網(wǎng)絡層必須依賴于端端之間的由DLL提供的可靠傳輸服務。

網(wǎng)絡層用于本地LAN網(wǎng)段之上的計算機系統(tǒng)建立通信,它之所以可以這樣做,是因為它有自己的路由地址結構,這種結構與第二層機器地址是分開的、獨立的。這種協(xié)議稱為路由或可路由協(xié)議。路由協(xié)議包括IP、Novell公司的IPX以及AppleTalk協(xié)議。

網(wǎng)絡層是可選的,它只用于當兩個計算機系統(tǒng)處于不同的由路由器分割開的網(wǎng)段這種情況,或者當通信應用要求某種網(wǎng)絡層或傳輸層提供的服務、特性或者能力時。例如,當兩臺主機處于同一個LAN網(wǎng)段的直接相連這種情況,它們之間的通信只使用LAN的通信機制就可以了(即OSI 參考模型的一二層)。

網(wǎng)絡層的一些主要標準如下:

ISO.DIS8208:稱為"DTE用的X.25分組級協(xié)議"

ISO.DIS8348:稱為"CO 網(wǎng)絡服務定義"(面向連接)

ISO.DIS8349:稱為"CL 網(wǎng)絡服務定義"(面向無連接)

ISO.DIS8473:稱為"CL 網(wǎng)絡協(xié)議"

ISO.DIS8348:稱為"網(wǎng)絡層尋址"

除上述標準外,還有許多標準。這些標準都只是解決網(wǎng)絡層的部分功能,所以往往需要在網(wǎng)絡層中同時使用幾個標準才能完成整個網(wǎng)絡層的功能.由于面對的網(wǎng)絡不同,網(wǎng)絡層將會采用不同的標準組合.

傳輸層

Transport Layer,位于OSI參考模型第四層,最終目標是向用戶一般指應用層的進程,提供可靠的服務。傳輸層主要定義了主機應該程序間端到端的連通性,它包含以下四項基本功能:

1.將應用層發(fā)往網(wǎng)絡層的數(shù)據(jù)分段或?qū)⒕W(wǎng)絡層發(fā)往應用層的數(shù)據(jù)段合并。

2.建立端到端的連接,主要是建立邏輯連接以傳送數(shù)據(jù)流。

3.將數(shù)據(jù)段從一臺主機發(fā)往另外一臺主機。在傳輸過程中通過計算校驗和以及通過流控制的方式保證數(shù)據(jù)的正確性,流控制可以避免緩沖區(qū)溢出。

4.部分傳輸層協(xié)議保證數(shù)據(jù)傳輸正確性。主要是在數(shù)據(jù)傳輸過程中確保同一數(shù)據(jù)不多次傳送也不丟失。同時還要保證數(shù)據(jù)包的接受順序與發(fā)送順序一致。

傳輸層協(xié)議主要有TCP/IP協(xié)議棧的TCP協(xié)議和UDP協(xié)議,IPX/SPX協(xié)議棧的SPX協(xié)議等。其中,TCP協(xié)議和SPX協(xié)議為應用程序提供可靠的,面向連接的服務;UDP協(xié)議提供不可靠的,無連接服務。

會話層

Session Layer,是OSI模型的第五層,通過執(zhí)行多種機制在應用程序間建立,維持和終止對話。會話層機制包括計費,話路控制,會話參數(shù)協(xié)商等。你可能常常聽到有人把會話層稱作網(wǎng)絡通信的"交通警察"。當通過撥號向你的ISP(因特網(wǎng)服務提供商)請求連接到因特網(wǎng)時,ISP 服務器上的會話層向你與你的 PC 客戶機上的會話層進行協(xié)商連接。若你的電話線偶然從墻上插孔脫落時,你終端機上的會話層將檢測到連接中斷并重新發(fā)起連接。會話層通過決定節(jié)點通信的優(yōu)先級和通信時間的長短來設置通信期限。

為給兩個對等會話服務用戶建立一個會話連接,應該做以下幾點工作:

1.將會話地址映射為運輸?shù)刂贰?/p>

2.選擇需要的運輸服務質(zhì)量參數(shù)(QOS)。

3.對會話參數(shù)進行協(xié)商。

4.識別各個會話連接

5.傳送有限的透明用戶數(shù)據(jù)

6.數(shù)據(jù)傳輸階段

這個階段是在兩個會話用戶之間實現(xiàn)有組織的,同步的數(shù)據(jù)傳輸.用戶數(shù)據(jù)單元為SSDU,而協(xié)議數(shù)據(jù)單元為SPDU.會話用戶之間的數(shù)據(jù)傳送過程是將SSDU轉(zhuǎn)變成SPDU進行的.

7 連接釋放

連接釋放是通過"有序釋放","廢棄","有限量透明用戶數(shù)據(jù)傳送"等功能單元來釋放會話連接的.會話層標準為了使會話連接建立階段能進行功能協(xié)商,也為了便于其它國際標準參考和引用,定義了12種功能單元.各個系統(tǒng)可根據(jù)自身情況和需要,以核心功能服務單元為基礎,選配其他功能單元組成合理的會話服務子集.會話層的主要標準有"DIS8236:會話服務定義"和"DIS8237:會話協(xié)議規(guī)范".

表示層

Presentation Layer,表示層保證源端數(shù)據(jù)能夠被目的端表示層理解和識別,對應用程序透明。表示層提供數(shù)據(jù)格式轉(zhuǎn)換服務,數(shù)據(jù)加密,數(shù)據(jù)表示標準等服務。表示層確定了數(shù)據(jù)傳輸時數(shù)據(jù)的組織方式。

應用層

Application Layer,OSI參考模型中的最高層,即第七層。應用層也稱為應用實體(AE),是模型中最接近用戶的一層,應該層支持應用程序,它由若干個特定應用服務元素(SASE)和一個或多個公共應用服務元素(CASE)組成。每個SASE提供特定的應用服務,例如文件運輸訪問和管理(FTAM)、電子文電處理(MHS)、虛擬終端協(xié)議(VAP)等。CASE提供一組公共的應用服務,例如聯(lián)系控制服務元素(ACSE)、可靠運輸服務元素(RTSE)和遠程操作服務元素(ROSE)等。主要負責對軟件提供接口以使程序能使用網(wǎng)絡服務。術語"應用層"并不是指運行在網(wǎng)絡上的某個特別應用程序 ,應用層提供的服務包括文件傳輸、文件管理以及電子郵件的信息處理。

以下是幾種常用的應用層協(xié)議

1.FTP:文件傳輸協(xié)議,F(xiàn)ile Transfer Protocol.是用于文件傳輸?shù)腎nternet標準。FTP提供可靠的面向連接服務,適合與遠距離,可靠性較差線路上的文件傳輸。

2.TFTP:簡單文件傳輸協(xié)議,Trivial File Transfer Protocol.也是用于文件傳輸,但TFTP使用UDP提供服務,被認為是不可靠的,無連接的。TFTP通常用于可靠的局域網(wǎng)內(nèi)部的文件傳輸。

3.SMPT:簡單郵件傳輸協(xié)議,Simple Mail Transfer Protocol.支持文本郵件的Internet傳輸。

4.POP3:Post Office Protocol,是一個流行的Internet郵件標準。

5.SNMP:簡單網(wǎng)絡管理協(xié)議,Simple Network Management Protocol.負責網(wǎng)絡設備監(jiān)控和維護,支持安全管理,性能管理等。

6.TELNET:是客戶機使用的與遠端服務器建立連接的標準終端仿真協(xié)議。

7.Ping:是一個診斷網(wǎng)絡設備是否正確連接的有效工具。

8.Tracert命令:和Ping命令類似,Tracert命令可以顯示數(shù)據(jù)包經(jīng)過的每一臺網(wǎng)絡設備信息,是一個很好的診斷命令。

9.HTTP:支持WWW和內(nèi)部網(wǎng)信息交互,支持包括視頻在內(nèi)的多種文件類型。是當今最流行的Internet標準。

10.DNS:Domain Name System 域名系統(tǒng)。把網(wǎng)絡節(jié)點的易于記憶的名字轉(zhuǎn)化為網(wǎng)絡地址。

11.WINS:Windows internet Name server 命名服務器,此服務可以將NetBIOS名稱注冊并解析為網(wǎng)絡上使用的IP地址。

12.BootP:Bootstrap Protocol 引導協(xié)議。是使用傳輸層UDP協(xié)議動態(tài)獲得IP地址的協(xié)議。

在OSI參考模型中,計算機傳送信息的問題分為7個較小且更容易管理和解決的小問題。每一個小問題都由模型中的一層來解決。之所以劃分為7個小問題,是因為它們之中的任何一個都囊括了問題的本身,不需要額外太多的信息就能解決。

篇7

關鍵詞:物聯(lián)網(wǎng) 石油測井 數(shù)據(jù)傳輸

中圖分類號:TE94 文獻標識碼:A 文章編號:1672-3791(2015)05(a)-0093-01

油田日常維護工作的順利開展,需要掌握油井的實際生產(chǎn)情況,因此需要通過儀器對油井的層數(shù)進行檢測。我國油井分布比較松散,因此對監(jiān)測的數(shù)據(jù)進行傳遞存在交的困難?;诖?,該文對物聯(lián)網(wǎng)石油測井數(shù)據(jù)的傳輸與控制系統(tǒng)的設計中的重要內(nèi)容進行了介紹,希望對相關工作人員能夠有所幫助。

1 物聯(lián)網(wǎng)

物聯(lián)網(wǎng)主要指的是末端設施和設備,主要包括工業(yè)系統(tǒng)、傳感器以及貼在射頻識別器上各種設備、攜帶無線終端的車輛和個人等。通過各種無線、有線,長距離或短距離的相互連通實現(xiàn)對數(shù)據(jù)傳輸。物聯(lián)網(wǎng)就是利用傳感器,實時對需要的數(shù)據(jù)進行采集、互動、連接,采集的信息的類型可以是電信號、光信號、化學信號等,利用各種可能存在的網(wǎng)絡接入,實現(xiàn)物與人、物與物之間的連接,從而實現(xiàn)對物品的智能化管理和識別。因此,可以簡單的將物聯(lián)網(wǎng)描述為,利用傳感器獲取物理環(huán)境信息,然后利用通信網(wǎng)絡對信息進行傳遞,再利用云計算平臺,實現(xiàn)對復雜信息的處理。

2 系統(tǒng)的設計與實現(xiàn)

2.1 設計方案

系統(tǒng)的具體實現(xiàn)方案:在測井現(xiàn)場利用傳感器獲取待測油井的數(shù)據(jù),將數(shù)據(jù)利用專用的電量將測得護具傳送給計算機,然后利用計算機對數(shù)據(jù)進行處理后,利用GPRS將傳遞到企業(yè)內(nèi)部,數(shù)據(jù)最終將會被送到測控中心,從而實現(xiàn)對數(shù)據(jù)的遠程傳輸

2.2 網(wǎng)絡傳輸協(xié)議

利用GPRS對數(shù)據(jù)進行傳輸面臨協(xié)議選擇,TCP和UDP是目前應用最廣泛的兩種協(xié)議,對協(xié)議的選擇需要依據(jù)系統(tǒng)運行的實際情況而定。TCP協(xié)議數(shù)據(jù)的傳遞面向連接具有較高的可靠性,比較適合應用在順序不重復、大批量的數(shù)據(jù)傳遞。但需要注意,TCP提供的數(shù)據(jù)傳輸不會對數(shù)據(jù)的便捷進行記錄,因此如果數(shù)據(jù)傳遞過程中采用的方式是數(shù)據(jù)包,需要對包的同步問題加以考慮。測井在數(shù)據(jù)傳遞過程中對數(shù)據(jù)量的要求較大,同時網(wǎng)絡環(huán)境十分復雜。此外,從目前的情況來看,在實際測試過程中,如果對TCP協(xié)議進行利用,數(shù)據(jù)在吞吐率上完全可以滿足使用要求。UDP協(xié)議與TCP相比更加簡單,靈活度高,建立連接較為容易,會對數(shù)據(jù)的邊界進行保留。其最大的不足它提供的數(shù)據(jù)包通信的方式并不可靠,在復雜的網(wǎng)絡環(huán)境下的應用要十分謹慎,如果程序?qū)Τ霈F(xiàn)的問題處理不當,可能會造成協(xié)議崩潰,從而導致系統(tǒng)無法正常運行。

2.3 測試通訊方案

為了對系統(tǒng)的可行性進行驗證,在中國聯(lián)通和中國移動兩種網(wǎng)絡的支持下對數(shù)據(jù)的傳輸效果進行驗證。在數(shù)據(jù)驗證過程中,利用自行編程的通訊程序?qū)τ吞飳嵉剡M行測試。測試過程中主要涉及到的性能有:RTK、吞吐量、時延、誤幀率的平均值。根據(jù)測試結果對公眾移動網(wǎng)絡是否滿足傳輸需求進行確定。同時,可以通過現(xiàn)場測試了解用戶要求,使其為通訊協(xié)議設計提供參考。

2.4 設計通訊協(xié)議

(1)雙發(fā)送隊列。

石油測井數(shù)據(jù)傳輸系統(tǒng),不僅要能夠?qū)崿F(xiàn)對測井中數(shù)據(jù)的傳遞,同時還應當實現(xiàn)文件的傳輸。測井數(shù)據(jù)傳輸在實時性上具有較高的要求,在文件的傳輸上實時性要求相對則較低,一般來說能夠在規(guī)定的一段時間內(nèi)完成文件傳輸即可。因此,在實際工作中,如果傳輸數(shù)據(jù)的寬帶有限,為了確保測數(shù)據(jù)傳遞的實時性,應當對測井數(shù)據(jù)和文件傳輸兩者制定相應的優(yōu)先級機制。方案如下:將發(fā)送隊列分為兩列,一列為測井數(shù)據(jù),另一列則為文件傳輸隊列,同時應當在文件傳送隊列上安置一個標志,對發(fā)送權限進行限制,該標志只有則測井數(shù)據(jù)發(fā)送結束后,才會生效,標志生效后,文件傳送隊列發(fā)送數(shù)據(jù),然后安置的標志將會再一次回到原位置,依次循環(huán)。

(2)后退N幀協(xié)議。

在數(shù)據(jù)傳輸過程中,如果采用簡單的協(xié)議,RTT的時延一般約為500ms,這對數(shù)據(jù)傳輸?shù)膶崟r性產(chǎn)生了一定影響,為了提高通訊協(xié)議效率,可以對后退N幀協(xié)議進行應用,這種協(xié)議處于非受限協(xié)議和等停協(xié)議之間,對其進行應用可以緩解因為傳輸距離過大,導致等停協(xié)議效率低問題的發(fā)生。后退N幀協(xié)議一般只在測井數(shù)據(jù)中使用,并不在文件傳輸中使用,對于文件傳輸?shù)木S護有更高層的ZMOG協(xié)議完成,在線程發(fā)送上只是簡單進行發(fā)送,并不會進行等待和確認。測井數(shù)據(jù)傳輸系統(tǒng)在通訊上需要是雙向的,因此在實際工程中,必須是由接收線程和發(fā)送線程兩者相互系統(tǒng)工作,接收線程和發(fā)送線程兩者之間的信息要能相互傳遞,其中最重要的一點就是,接收線程應當能夠?qū)RQ應當信號傳送給發(fā)送線程,從而確保發(fā)送線程在運行過程中能夠順利完成發(fā)送任務,確保整個系統(tǒng)的安全運行。

3 結語

計算機技術的高速發(fā)展,使測井數(shù)據(jù)的數(shù)據(jù)的實時性得到進一步提高。在石油測井數(shù)據(jù)的傳輸與控制系統(tǒng)的設計過程中,要對不同的問題進行針對性研究,并且要通過大量的數(shù)據(jù)來對系統(tǒng)的功能進行確定,確保系統(tǒng)在日后的使用過程中能夠達到理想的效果。

參考文獻

[1] 任哲.嵌入式實時操作系統(tǒng)μC/OS-II 原理及應用[M].北京:北京航空航天大學出版社,2019.

[2] 孫昊,曹玉強,杜玉芳.ARM處理器啟動代碼分析與編程[J].工業(yè)控制計算機,2005(11):54-55.

篇8

【關鍵詞】Android 視頻監(jiān)控 系統(tǒng)設計 H.264編碼 應用

近年來,智能手機的快速發(fā)展推動了Android手機操作系統(tǒng)的開發(fā)和利用,該系統(tǒng)的優(yōu)勢在于便于攜帶、系統(tǒng)小巧、功能全面,因此也使得基于Android平臺的視頻監(jiān)控技術得研發(fā)和應用。傳統(tǒng)的視頻監(jiān)控系統(tǒng)由于受線纜或光纖的帶寬限制,無法實現(xiàn)實時的視頻信號傳輸,而Android平臺在無線網(wǎng)絡的支持下成功的解決了一這問題,從而進一步促進了遠程監(jiān)控、可視電話、電視會議等遠程視頻實時監(jiān)控技術的廣泛應用。

1 視頻監(jiān)控技術概述

視頻監(jiān)控技術的應用時間比較久遠,以往在安防領域發(fā)揮了非常大的作用,是公安部門維持社會穩(wěn)定、打擊犯罪的重要技術手段。經(jīng)過多年的發(fā)展,視頻監(jiān)控技術經(jīng)歷了模擬監(jiān)控系統(tǒng)、數(shù)字視頻監(jiān)控系統(tǒng)、網(wǎng)絡視頻監(jiān)控系統(tǒng)等三個重要發(fā)展階段,隨著移動網(wǎng)絡的快速發(fā)展,視頻監(jiān)控技術開始朝向以移動流媒體技術為代表的移動視頻監(jiān)控方向發(fā)展,手機等移動設備開始具備實時監(jiān)看遠程動態(tài)畫面的功能,由此也將視頻監(jiān)控技術的應用范圍拓展到了教育、政府、娛樂、醫(yī)療、酒店、運動等多個領域,實現(xiàn)了“隨時隨地,自由掌控”的監(jiān)控,為人們的生產(chǎn)、生活提供了更簡單、便利、及時的監(jiān)控解決方案。

2 視頻監(jiān)控系統(tǒng)的結構設計及應用

目前,基于Android平臺的視頻監(jiān)控系統(tǒng)主要由采集模塊、編碼模塊、視頻傳輸模塊、解碼模塊、顯示模塊等五大模塊共同構成,相關設計也是圍繞這五大模塊進行的。

2.1 視頻采集模塊

基于Android平臺的視頻信號采集工作是由采集模塊完成的,通過手機攝像頭可以獲得YUV420格式的視頻流,而相關模塊則可通過對Android應用層的代碼編寫實現(xiàn)。

2.2 編碼模塊

目前,Android平臺視頻監(jiān)控系統(tǒng)的數(shù)字視頻編碼標準主要有兩種,一種是由MPEG制定的MPEG-1、MPEG-2、MPEG-4編碼標準;而另一種則是由ITU一T制定的H.261、H.263視頻編碼標準。為進一步促進視頻監(jiān)控系統(tǒng)在多媒體通信方面的應用,MPEG和VCEG聯(lián)手共同開發(fā)了當今最先進的視頻編碼標準――H.264。

雖然該標準依然采用了以往的壓縮標準架構,但是H.264在此基礎上增加了更多新的特性。比如,H.264標準包含了網(wǎng)絡抽象層(NAL)和視頻編碼層(VCL)兩層結構,網(wǎng)絡抽象層的功能是打包、傳輸數(shù)據(jù),而視頻編碼層的功能是壓縮視頻編碼,這樣的分層結構對信號的傳輸和編碼工作進行了分離,使得H.264標準在面對復雜的通信環(huán)境時,依然可以利用不同的網(wǎng)絡進行視頻信號的傳輸工作并保證良好的視頻數(shù)據(jù)質(zhì)量。

2.3 傳輸模塊

視頻數(shù)據(jù)傳輸?shù)膽弥饕蹾TTP、RTSP、RTP、RTCP協(xié)議的約束。TCP和UDP協(xié)議主要作用于傳輸層,HTTP則是基于TCP(傳輸控制協(xié)議)的超文本傳輸協(xié)議。在一對一或一對多的情況下,RTP可以保證流媒體數(shù)據(jù)流與時間信息的同步正常工作。一般情況下,RTP需要使用UDP進行數(shù)據(jù)傳輸,因此UDP是建立RTP的基礎。另外,RTP還需要供助RTCP(實時傳輸協(xié)議)彌補自身沒有可靠的傳送機制的弱點,因此只有讓RTP和RTCP共同協(xié)作才能實現(xiàn)流量和擁塞的有效控制。同時,RTCP作為應用層協(xié)議,其位置處于RTP和RTCP協(xié)議層之上,多媒體數(shù)據(jù)的傳輸則是通過IP網(wǎng)絡利用傳輸機制的TCP和RTP實現(xiàn)數(shù)據(jù)傳輸。RTSP則用于實時數(shù)據(jù)發(fā)送時對音視頻流的遠程控制,如對流媒體的播放、暫停、記錄等相關操作。SDP則用來描述RTSP的會話描述協(xié)議,用于說明會話的基本屬性。結合這些協(xié)議在視頻監(jiān)控系統(tǒng)中起到的作用,本文設計的Android平臺視頻監(jiān)控系統(tǒng)主要采用RTP、RTSP、RTCP、HTTP等四個協(xié)議構建系統(tǒng)的傳輸模塊。

視頻監(jiān)控系統(tǒng)中的流媒體系統(tǒng)需要由編碼器、流媒體服務器、客戶端播放器三個基本部件構成。編碼器的作用在于將采集到的原始視頻數(shù)據(jù)轉(zhuǎn)換成流媒體格式文件,而這些編碼后的文件則由流媒體服務器進行接收和轉(zhuǎn)發(fā),客戶端播放器則將接收到的文件進行解碼、播放。流媒體傳輸?shù)姆绞娇煞譃閮煞N:

(1)順序流式傳輸。這種方式是基于HTTP或FTP服務器進行文件傳輸?shù)姆绞?,可以保證完全無損的數(shù)據(jù)下載,可以有效保證視頻的質(zhì)量,也便于管理和用戶使用。但這種方式對于網(wǎng)絡傳輸速率的要求較高,通常需要等待較長時間,不適用于實時性的隨機訪問。

(2)實時流式傳輸。這種方式是基于傳輸網(wǎng)絡協(xié)議和專用的流媒體服務器進行文件傳輸?shù)?,由于匹配了帶寬和無線網(wǎng)絡,可以支持實時性的現(xiàn)場直播,適用于用戶的隨機訪問和后退操作。傳輸網(wǎng)絡協(xié)議需要與防火墻進行配置,在管理方面存在一定的復雜性。同時該方式必須與帶寬和無線網(wǎng)絡匹配,一旦網(wǎng)絡擁塞或設備出現(xiàn)低速連接狀態(tài)時,就會出現(xiàn)包括丟幀在內(nèi)的視頻質(zhì)量下降現(xiàn)象。

2.4 解碼模塊

解碼模塊的作用就是對編碼的過程進行逆操作,因此解碼采用的標準也是編碼采用的H.264。解碼器一般由視頻數(shù)據(jù)的解碼部分和視頻的顯示部分兩個部分構成。解碼部分主要是采用Android NDK+C機制進行實現(xiàn),顯示部分則利用Android SDK+Java機制由Android提供的組件實現(xiàn)。兩個部分的通信則由java提供的jni機制實現(xiàn)。解碼的整體流程主要由前段碼流處理、H.264解碼和后段視頻顯示三個功能模塊實現(xiàn):前段碼流處理負責讀取文件,在分隔出NAL后將文件效由底層解碼;H.264解碼則負責圖像的重建工作,是解碼過程的核心部分;后端視頻顯示則將解碼后的文件通過客戶端進行顯示。

2.5 顯示模塊

利用Android系統(tǒng)自帶的顯示器將解碼后的數(shù)據(jù)流進行實時視頻顯示,并保證視頻顯示的效果。

3 結語

本文基于Android平臺的特點,利用移動流媒體技術對移動視頻監(jiān)控系統(tǒng)采取了五個模塊的系統(tǒng)設計,充分考慮到了視頻監(jiān)控系統(tǒng)的安全性、穩(wěn)定性和實時性。

參考文獻

[1]魏崇毓,張菲菲.基于Android平臺的視頻監(jiān)控系統(tǒng)設計[J].計算機工程,2012(14):214-216.

[2]郭永清.基于Android平臺的視頻監(jiān)控系統(tǒng)的設計研究[D].西安科技大學,2012.

[3]張賀.基于Android的智能視頻監(jiān)控系統(tǒng)設計[D].成都理工大學,2015.

作者單位

篇9

【關鍵詞】機房管理;FTP;IIS Serv-U

計算機機房是職業(yè)院校里最重要的實驗室之一,是各專業(yè)計算機類課程的主要實踐場所,機房維護的好壞從一定程度上影響著計算機類課程實驗、實習和設計等實踐教學環(huán)節(jié)的順利進行。

一、機房管理的任務及面臨的問題

機房管理的主要任務是完成基本的教學功能以及訪問互聯(lián)網(wǎng)功能。但現(xiàn)實情況是一個機房一學期內(nèi)要承擔多門課程的實驗需求,相應的教學軟件必須安裝齊全。對于驗證型實驗,要提供滿足試驗要求的基本環(huán)境;對于開發(fā)型實驗,試驗結果可以通過網(wǎng)絡提交到服務器,方便教師及時檢閱指導。學生機只是一個試驗的平臺。

在機房的日常管理中,存在以下問題:

1.系統(tǒng)保護與數(shù)據(jù)存儲的矛盾

在機房管理中為了增強穩(wěn)定性,減少維護工作量,一般都選購帶有還原保護系統(tǒng)的品牌機,或者安裝還原軟件。學生在使用時保存在計算機硬盤的資料會隨著計算機的重新啟動而被還原掉。學生下載的軟件或所做的作業(yè)不能在機房的電腦里保存。另外,對于公共機房來說,可能存在的問題是,今天學生在這個機房上課,而下次學生可能在另一個機房上課。因此,學生大都采用自帶U盤或其他存儲設備的方式,但允許使用U盤也容易帶來病毒傳播的問題。

2.數(shù)據(jù)共享問題

教師上課時所需素材等文檔資料可以通過多媒體教學軟件分發(fā)給學生,或者通過文件夾共享讓學生自己獲取。在學生完成作業(yè)后,教師需逐臺機器檢查學生作業(yè),這樣效率非常低。當然可以通過多媒體教學軟件來在線提交。但不同老師使用的教室里,作業(yè)如何區(qū)別保存也是個問題。

在使用共享文件夾方式的時候,需要使用SERVER版的操作系統(tǒng)如Windows Server2003來解決連接數(shù)的問題,且設置本身也是一個較大的工程,另外在這種情況下也容易發(fā)生學生抄襲作業(yè)或惡意刪除其他同學的文件等問題。

3.資料存檔問題

從規(guī)范實踐教學管理的角度出發(fā),實踐教學的實驗結果、實驗數(shù)據(jù),也需要進行存檔。那么如何建立起實踐環(huán)節(jié)的教學檔案是一個迫切需要解決的問題。

二、幾種解決方法

1.使用教學軟件

現(xiàn)在學校機房一般都安裝有多媒體電子教室軟件,該軟件雖說有“文件傳輸”和“遠程命令”功能,但是使用中發(fā)現(xiàn)“文件傳輸”功能不盡如人意,傳輸大一些的文件或圖片時往往出現(xiàn)問題,造成文件丟失或損壞。尤其是給學生機作業(yè)要求及素材、學生上交作業(yè)文件或者教師機接收作業(yè)文件這些文件傳輸環(huán)節(jié)往往也遇到困難。

2.使用“網(wǎng)上鄰居”

“網(wǎng)上鄰居”作為局域網(wǎng)內(nèi)計算機之間傳輸文件的橋梁,在實際應用中發(fā)揮過重要的作用。但從WindowsXP以后,“網(wǎng)上鄰居”的設置不再像以前那么方便了,需要啟用GUEST賬戶,啟用Microsoft網(wǎng)絡上的文件與打印機共享,還要安裝“網(wǎng)絡客戶”選項,最重要的是要檢查計算機上是否已正確安裝啟動了“計算機瀏覽器服務(ComputerBrowserService)”等。另外,經(jīng)常會出現(xiàn)計算機之間無法互訪的問題。

WindowsXP“網(wǎng)上鄰居”在使用時系統(tǒng)會搜索自己的共享目錄和可作為網(wǎng)絡共享的打印機以及計劃任務中和網(wǎng)絡相關的計劃任務,然后才顯示出來,這樣速度顯然會慢很多,而且在傳輸文件時對系統(tǒng)資源的消耗較大。

另外,學生機上的“網(wǎng)上鄰居”功能容易出現(xiàn)問題,往往是設置或者是病毒感染的問題,再加上學生機都有還原卡或還原精靈,因此出現(xiàn)問題不好解決,尋找新的方法實現(xiàn)學校機房的文件傳輸成為擺在我們面前的迫切任務。

3.使用FTP

FTP是FileTransferProtocol(文件傳輸協(xié)議)的縮寫,用來在兩臺計算機之間互相傳送文件。FTP服務作為Internet最古老的服務之一,無論在過去還是現(xiàn)在都有著不可替代的作用。在企業(yè)中,對于一些大文件的共享,通常采用FTP這種形式來完成,并且由于FTP能消除操作系統(tǒng)之間的差異,對于不同的操作系統(tǒng)之間共享文件的作用就顯得尤為突出。FTP傳輸性能穩(wěn)定,占用系統(tǒng)資源小,而且傳輸速度快、效率高,安全性好。這些方面都是網(wǎng)上鄰居比不上的。

FTP在機房管理中的應用已越來越廣泛,包括軟件資源、課件資源的,學生隨堂作業(yè)、課后作業(yè)的上交等,非常適合內(nèi)部資源共享。使用FTP服務器還可以帶來其他好處:FTP服務器的日志文件里記錄著提交作業(yè)的時間、提交作業(yè)的機器的IP地址,還可以設置權限,例如只能上傳不能下載,這樣就可以防止學生復制別人的作業(yè)。也可以在網(wǎng)頁上制作出FTP服務器的網(wǎng)址的超級鏈接,學生只需要點擊該鏈接就可以直接打開FTP服務器,然后把作業(yè)文件粘貼到這里或者拖拽到這里就完成了上交;同樣,素材的下載也很簡單。

三、常用的FTP軟件

傳統(tǒng)地,在采用Windows操作系統(tǒng)的服務器上,會利用系統(tǒng)自帶的IIS來架設FTP服務器。這種方法實施簡單,能實現(xiàn)的功能也很簡單,在訪問權限管理方面較為欠缺,僅僅有讀取和寫入兩種權限;用戶管理依賴于Windows系統(tǒng)內(nèi)建的用戶,使用起來不方便。

目前市面上的FTP服務器軟件有很多種,Serv-U是目前眾多的FTP服務器軟件之一。使用Serv-U,能夠?qū)⑷魏我慌_PC設置成一個FTP服務器。這樣,用戶或其他使用者就能夠使用FTP協(xié)議,通過在同一網(wǎng)絡上的任何一臺PC與FTP服務器連接,進行文件或文件夾的創(chuàng)建、復制、移動和刪除等。雖然目前FTP服務器端的軟件種類繁多,相互之間各有優(yōu)勢,但是Serv-U憑借其獨特的功能倍受歡迎。

四、建立FTP服務器

(一)利用IIS來構建FTP服務器

在架設FTP網(wǎng)站時,對于僅僅作為共享文件這種服務而沒有其他特殊要求的,可通過Windows2000/2003操作系統(tǒng)的IIS組件來完成。步驟如下:

(1)IIS安裝,可按照“開始”“設置”“控制面板”“添加/刪除程序”,打開“添加/刪除程序”對話框,選中“添加/刪除Windows組件”。

(2)選中“Internet信息服務(IIS)”,查看其詳細信息。

(3)選中“文件傳輸協(xié)議(FTP)服務器”項后,單擊確定,接下來按照向?qū)е涟惭b完成。

(4)打開“開始”“程序”“管理工具”“Internet信息服務”,打開IIS控制臺。

(5)單擊“默認FTP站點”,在右鍵快捷菜單中選中“屬性”,打開“默認FTP站點屬性”對話框。

(6)在“FTP站點”選項卡中,需要修改“說明”為容易識別的標識,IP地址修改為當前主機的某個IP地址。如本機修改為私有地址“192.168.1.1”,“TCP端口”為默認的FTP端口“21”。

(7)在“安全帳號”中選中“允許匿名連接”,如果對于客戶端登陸時需要進行身份驗證,則可通過“瀏覽”來選中服務器的Windows用戶。

(8)在“消息”選項卡中添加FTP服務器的登陸歡迎信息和退出信息。

(9)在“主目錄”選項卡中選擇FTP服務器向外提供服務的主目錄,此處可選擇“此計算機上的目錄”,通過瀏覽進行選擇,或者選擇“另一計算機上的共享位置”,這是FTP服務器向外提供服務的主目錄在其他主機上,格式為“\\{服務器}\{共享名}”,在FTP站點目錄下的“讀取”、“寫入”、“日志訪問”對FTP站點的權限進行配置,在此處出于安全考慮只為匿名anonymous用戶分配“讀取”權限而不分配“寫入”權限。

(10)在“目錄安全性”選項卡中對FTP服務器的訪問控制權限進行分配,可通過此處將FTP服務器的訪問權限授權給某部分IP用戶或者拒絕來自某些IP用戶的訪問。注意當選擇了“授權訪問”后,在列表中的IP地址將被拒絕,如選擇“拒絕訪問”,列表中的IP地址用戶將被授權。

至此,F(xiàn)TP服務器架設成功。

(二)利用Serv-U構建FTP服務器

Serv-U設置簡單,功能強大,性能穩(wěn)定,現(xiàn)已成為絕大多數(shù)用戶建立FTP服務器的首選軟件。用Serv—U建立FTP服務器的步驟:

首先,在服務器上安裝Serv—U軟件。

第二步,運行Serv—U,在“安裝向?qū)А钡闹敢?,對FTP服務器進行基本的配置。

第三步,設置服務器的“訪問最大速度”和“允許的最大用戶訪問量”,以保證服務器的最佳運行狀態(tài),使服務器正常無故障運行。如果不設置“最大訪問速度”,服務器將會利用所有可能的帶寬為客戶提供服務,而過多的用戶可能會占用一切可能的帶寬,從而影響其他的網(wǎng)絡應用。

第四步,為用戶設置登陸名和密碼。并設置用戶權限。Serv—U支持匿名訪問,但是作為專業(yè)的FTP站點,一般只允許授權用戶訪問,所以用戶登陸FTP服務器時需要有一個帳號和相應的密碼,服務器的管理人員在Serv—U中為用戶設定其帳號和密碼。通過規(guī)定每個用戶在訪問該FTP服務器時的權限,決定了用戶可以訪問哪些文件、不能訪問哪些文件、以何種方式訪問,從而確保了網(wǎng)絡信息的安全。

第五步,服務器其他屬性的設置。

通過以上操作,即建好了內(nèi)網(wǎng)FTP服務器。

Serv-U可以做到一站多用戶,不同用戶登錄可以綁定不同的工作目錄。針對作業(yè)區(qū)別保存的問題,我們在Serv-U中建立兩個帳號,分別為:CAD和PS,用戶CAD登錄后對應工作根目錄為D:\CAD,用戶PS登錄后對應工作根目錄為D:\PHOTOSHOP;然后,分別在各自目錄下再建立用于上交作業(yè)的子目錄D:\CAD\作業(yè),D:\PHOTOSHOP\作業(yè);最后在Serv-U中,設置用戶CAD對工作根目錄D:\CAD僅有讀取權限、對目錄D:\CAD\作業(yè)具有寫入和追加權限,不具備讀取和刪除權限,以防止同學誤刪和抄作業(yè);用戶PS的設置類似。

這樣一來,不同班級不同課程的學生,打開同一IP的FTP站點,輸入不同的用戶名就會進入各自對應的工作目錄,利用Serv-U細膩的權限管理,使學生誤刪和抄作業(yè)現(xiàn)象得到較好控制。

參考文獻:

[1]李衛(wèi)東,徐景波.學校機房文件傳輸方法探討[J].開封大學學報,2007年9月第21卷第3期

[2]王宏.教學資源庫的FTP設計與實現(xiàn)[J].昌吉學院學報,2010年第6期

篇10

關鍵詞:FTP;備份還原系統(tǒng);煙草工業(yè)

引言

隨著工業(yè)自動化技術的發(fā)展,煙草機械行業(yè)中客戶對產(chǎn)品的用戶體驗要求日益提高,同時,與國際同行相比,國內(nèi)煙草機械行業(yè)也由起初的望塵莫及、望其項背進入同臺競技的新階段,而隨著“中國制造2050”戰(zhàn)略的提出,國內(nèi)煙草機械行業(yè)的最終目標必然是與國際同行實現(xiàn)并駕齊驅(qū)。在此大背景下,控制系統(tǒng)作為煙草機械的一大優(yōu)勢,登上競技臺與國外巨頭進行競爭。PLC、伺服運動控制及人機界面(HMI)作為煙草機械工控系統(tǒng)中最重要的三個子系統(tǒng),在實際工程應用中經(jīng)常需要對其不同版本進行備份,再根據(jù)實時要求進行還原操作,然而三個子系統(tǒng)相對獨立,必須分別進行備份還原并添置硬件,不便于用戶的實際操作。為了解決上述問題,提高機器智能化水平,更好的為用戶服務,特別開發(fā)了一套基于VisualStudio2010的備份還原系統(tǒng),一次性完成PLC、伺服運動控制系統(tǒng)及人機界面三個子系統(tǒng)的備份還原任務。

一、備份還原系統(tǒng)的原理

整個工業(yè)控制系統(tǒng)主要包括主PLC、上位機HMI、ELAU運動控制系統(tǒng)以及后續(xù)用戶添加的專用系統(tǒng)如數(shù)據(jù)采集系統(tǒng),如圖1所示。備份還原系統(tǒng)在上位機HMI上運行,通過FTP協(xié)議實現(xiàn)與主PLC、ELAU運動控制器及后續(xù)用戶添加的專用系統(tǒng)控制器實現(xiàn)數(shù)據(jù)傳輸,完成PLC系統(tǒng)的控制數(shù)據(jù)、HMI運行數(shù)據(jù)、上位機桌面信息、ELAU運動控制數(shù)據(jù)以及用戶的專用系統(tǒng)數(shù)據(jù)的備份還原。整個系統(tǒng)所用的FTP通訊協(xié)議全稱是FileTransferProtocol[1],基于此協(xié)議可以實現(xiàn)文件在處于同一局域網(wǎng)中不同電腦間的傳輸[2],并可以保證整個傳輸過程的可靠穩(wěn)定性[3],因此在互聯(lián)網(wǎng)領域被廣泛應用[4]。FTP協(xié)議屬于典型的C/S模式[1],文件傳輸過程如圖2所示,其中提供FTP服務的計算機為FTP服務器,用戶的本地計算機為FTP客戶端;將文件從FTP服務器傳輸?shù)娇蛻舳说倪^程為下載,將文件從客戶端傳輸至FTP服務器的過程為上傳。FTP服務的實時屬性要求用戶在訪問FTP服務器之前必須登錄,只有登錄成功的用戶才能訪問、查詢、讀寫該服務器上的資源[1]。但是,這種登錄方式在某種程度上會制約某些公共資源的共享,因此,大部分FTP服務器還會提供匿名(anonymous)FTP服務。匿名FTP服務的實質(zhì)是:提供服務的機構在它的FTP服務器上建立一個公開賬戶(通常為Anonymous),并賦予該賬戶訪問公共目錄的權限,以提供免費服務。然后,當用戶訪問此FTP服務器時,則不需要輸入用戶名和密碼;如果需要,則是輸入系統(tǒng)默認的公開賬戶即用戶名為“anonymous”,密碼為空。

二、備份還原系統(tǒng)的功能模塊

VisualStudio2010通過其命名空間下的NetWorkCredential類、FtpWebRequest類和FtpWebResponse類提供對FTP的全面支持。其中,NetWorkCredential類用于驗證客戶端身份,當需要驗證訪問權限時,可使用這個類提供FTP服務器所需的用戶名及密碼;FtpWebRequest類用于實現(xiàn)FTP客戶端所有請求;FtpWebResponse類用于封裝FTP服務器對客戶端請求的響應。FtpWebResponse對象提供操作的狀態(tài)及從服務器下載的所有數(shù)據(jù),獲取FTP響應時,需調(diào)用FtpWebRequest對象的GetResponse方法獲取。2.1FTP服務器連接模塊。實現(xiàn)FTP服務器之間的文件傳輸,必須要運用服務器的正確用戶名和密碼成功登錄服務器,同時賦予某項操作權限,否則FTP命令將不能成功執(zhí)行,下列語句即為驗證客戶端身份的示范。上述語句中的NetWorkCredential類非常重要,在后續(xù)的FTP各項操作中如讀取、寫入及刪除等都需要調(diào)用它。2.2FTP讀取寫入模塊。依照實際需求,對FTP服務器的數(shù)據(jù)處理方法有很多比如讀取、寫入、刪除、復制、創(chuàng)建及重命名文件等等,其中被廣泛應用的主要有讀取寫入兩種。除讀取操作以外,后續(xù)幾種操作之前都需要首先在客戶端顯示服務器的文件詳細信息,即通過FtpWebResponse對象獲取響應,再通過一系列的處理轉(zhuǎn)換成文件名、目錄名及文件大小等信息。獲取以上信息之后,客戶端即可對服務器中文件進行讀取寫入操作,這兩種操作數(shù)據(jù)傳輸方式類似。讀取操作利用WebRequestMethods.Ftp.DownloadFile類,寫入操作利用WebRequestMethods.Ftp.UploadFile類,然后打開responseStream數(shù)據(jù)通道,進行數(shù)據(jù)傳輸。2.3文件及文件夾的遍歷模塊。在實際工程應用中,F(xiàn)TP服務需要傳輸?shù)奈募愋筒粌H僅是單一的文件,有時會有文件夾嵌套文件、文件夾嵌套文件及文件夾等等情況,為保證數(shù)據(jù)傳遞的準確性及完整性,必須將以上種種情況考慮進文件及文件夾遍歷模塊設計中。

三、備份還原系統(tǒng)界面

選擇需要保存或恢復的選項以及文件所在位置,點擊“保存”或是“恢復”按鈕,然后點擊“開始”,即可開啟保存或恢復進程;點擊“退出”,即關閉備份還原系統(tǒng)。

四、結語

通過實驗室測試可證,備份還原系統(tǒng)可成功將PLC、HMI以及伺服控制系統(tǒng)一次性備份到存儲設備中,并且還可以存儲時間為依據(jù)存儲不同的版本,用戶根據(jù)需要對各個子系統(tǒng)進行還原,大大提高了備份還原操作的效率以及自由度。

參考文獻

[1]鄭阿奇.VisualC#網(wǎng)絡編程[J].北京:電子工業(yè)出版社,2011:237-251.

[2]顧煜炯,林慶乙,賀徙.基于UDP與FTP協(xié)議的遠程振動監(jiān)測與故障診斷系統(tǒng)網(wǎng)絡通信方法[J].儀器儀表學報,2007(06):413-414.

[3]耿強,黃雪琴.基于IRIS軟件的FTP協(xié)議分析[J].科技信息,2012(19):107.

[4]張艷,華東.基于FTP的考試文件傳輸系統(tǒng)的研究[J].南京審計學院學報,2005(2):66-70.