udp協議范文第1篇
關鍵詞：可靠UDP,確認重傳,滑動窗口
由于傳統的數據傳輸協議所針對的業務不同,在數據傳輸的速度和可靠性之間不能達到很好的平衡。車險理賠系統中采用的是移動理賠的思想,手持終端機通過移動通信網絡和后臺中心系統進行數據交互。目前國內的通信事業并不是很發達,信號覆蓋率并不全面,移動通信網絡的帶寬和傳輸質量會受到地域的影響,為確保理賠現場與后臺系統間數據的及時可靠傳輸,需要基于移動通信的網絡環境設計高效可靠的數據傳輸功能。本章在UDP傳輸協議基礎上,通過應用層封裝和可靠性設計的方法,采用數據包的確認重傳、流量控制等機制,設計并實現基于UDP協議的可靠數據傳輸功能。
1 TCP與UDP的對比
TCP和UDP都屬于傳輸層協議,負責承擔數據傳輸的任務[1]。兩者之間的主要區別有:
(1) TCP和UDP是傳輸層的兩個協議,它們最大的區別是是否面向連接。TCP,在客戶端和服務器端進行通信之前,首先要交換傳輸層控制信息,為雙方的通信做好準備。UDP是一個非連接的協議,傳輸數據之前雙方不建立連接,當傳送數據時,簡單的抓取來自應用程序的數據,并盡可能快的把數據傳送到網絡上。
(2) UDP協議的數據傳輸不需要維護收發狀態和連接狀態等,與TCP相比,網絡有效利用率得到很大的提高。
(3) TCP協議提供數據確認重傳、擁塞控制等可靠性保證,UDP協議不提供可靠性保證,也不提供流量控制。
TCP協議由于需要確認的狀態和對數據包的操作過多,數據傳輸的速度不高且網絡延遲較大,所以雖然協議可靠但并不適合面向移動通信的數據傳輸;而UDP協議由于不用建立連接,沒有超時重發等可靠機制,網絡延遲小且數據傳輸速度很快。本文設計的理賠系統面向移動通信網絡實現理賠現場與后臺系統間的數據傳輸,網絡環境不如光纖接入網絡穩定可靠,對數據的高效可靠傳輸有著很高的要求。因此,本章選用UDP協議,并在其基礎上,設計了連接確認、數據確認等可靠機制,滿足了系統對于高效可靠傳輸功能的需求。
2基于UDP 改進的可靠傳輸協議實現
2.1 主要功能模塊及任務結構
綜合文獻【2】的可靠機制描述,可靠UDP數據傳輸協議的模塊結構如圖1所示。
從模塊結構上看,本模塊主要由以下幾個任務實現模塊功能:
通信處理模塊
1) 發送方發起數據傳輸請求,三次握手成功后,發送方進入數據包封裝模塊。
2) 超時定時器的啟動和關閉。
3) 當數據傳輸結束時,接收方向發送方主動發起傳輸結束的請求。
數據包封裝/解析模塊
1) 發送方將要發送的的數據按照協商大小分塊,排序。
2) 發送方將分塊的數據協商的數據報文結構封裝成要發送的消息包。
3) 接收方讀取數據包后根據協商的數據報文結構拆分數據包,根據數據包的類型讀取信息。
消息發送/接收模塊
1) 發送方判斷發送隊列和消息隊列是否為空后,將要發送的數據包處理后發送。
2) 接收方從接收隊列中讀取數據包。
數據重組模塊
1) 由于網絡問題,發送方按序發送的數據包不一定會按序到達,所以接收方在經過數據包解析模塊讀取數據后,根據該消息的字節序號判斷是否為亂序的分組。
2) 若是順序的分組,將分組與以前收到的消息按序排列;若是要求重傳的分組,將該分組放入到所應在的位置中。
3) 如果滿足重發條件,則向發送方發送重發包請求。
2.2 核心事件處理流程
2.2.1 通信處理進程
通信處理模塊中的通信處理進程主要負責三次握手的發起和確認的請求,數據傳輸結束后結束連接等任務。具體流程見圖2。首先,通信的接收方發起握手的請求,即建立一個虛連接,雙方必須確保該連接成功建立后才可以進行下一步數據傳輸的操作。然后,在接收方一端啟動定時器,接收方的數據處理進程接收發送方發送的數據,同時接收方根據定時計時器發送反饋消息;或判斷接收到的報文數,當達到數據包累積計數器設定的數值時,向發送方發送反饋消息。
2.2.2 發送方發送報文
數據報文的發送,主要是發送方向接收方發送數據報文和消息報文,流程如圖3所示,具體的算法為:
3 實驗結果與分析
3.1 開發環境
系統的編程實現是在Windows XP上進行的,使用的編程工具為Visual C++6.0。
3.2系統測試
3.2.1 測試環境
本測試是是在無線通信網絡下進行的,配置了兩臺計算機用作數據間收發的測試,操作系統為Windows XP。華為E2613G上網卡兩張,用于連接無線網絡,測試拓撲結構如圖4所示。
3.2.2 測試內容
本測試采用傳輸不同大小文件的方式來對數據速度進行測試,每次傳輸重復測試三次,然后取平均值作為參考數據,測試結果見表1和表2。其中,表1是在最大連接速率7.2Mbps環境下的測試結果,表2是在連接速率為2.2Mbps環境下的測試結果。
由表1可見,在移動通信的網絡連接環境為7.2Mbps時,當傳輸1MB的數據時,TCP協議測試耗時9.75s,平均傳輸速度約為105KB/s;可靠UDP耗時8.25s,平均傳輸速度約為124KB/s。當傳輸數據為32MB時,TCP耗時295.89s,平均傳輸速度約為120KB/s;可靠UDP耗時197.05s平均傳輸速度約為168KB/s。
由表2可見,在移動通信的網絡連接環境為2.2Mbps時,由于連接環境較差,測試文件并不大,當傳輸0..36s,平均傳輸速度約為21KB/s;可靠UDP耗時190.81s,平均傳輸速度約為43KB/s。
由此可得出:
(1) 可靠UDP傳輸協議的優勢隨著傳輸數據量的增大而越來越明顯。
(2) 可靠UDP傳輸協議的優勢隨著網絡環境的變差而越來越明顯。
參考文獻
[1]Douglas E.Comer.用TCP/IP進行網際互聯——原理、協議與結構(第五版)[M].林瑤,張娟,王海,等譯.北京:電子工業出版社,2009.
[2]王玨,何秋燕,王露凱.基于UDP改進的可靠傳輸協議設計[J].電子世界,2014(22).
[3]王繼剛,顧國昌,徐立峰,等.可靠UDP數據傳輸協議的研究與設計[J].計算機工程與應用,2006(15):113-116.
[4]靳海力.一種增強型可靠UDP的設計及應用[D].合肥:中國科學技術大學,2009.
udp協議范文第2篇
網絡技術的快速發展在推動信息廣域、多層、便捷交互的同時,也給網絡安全和管理帶來了諸多挑戰。一方面是共享豐富多彩信息資源帶來便利的愿望十分迫切,另一方面是切實降低不良信息影響和有效發揮網絡功能效益的要求更加突顯。特別對企事業單位、部隊院校和部門機構而言,通過有效的方式監管內網,促進安全、合理、有序、高效使用網絡資源是非常必要的。提出的網絡監控系統基于UDP協議,針對遠端計算機屏幕進行實時監控,并對操作人員及客戶端信息采用數據庫實施驗證管理。
2 系統總體方案
2.1 網絡體系結構
本系統利用現有局域網,整體采用C/S體系結構,在服務器端實現對選定的客戶端進行屏幕監控。為確保系統具有良好的可靠性、實時性、可伸縮性、高效性與經濟性,采取服務器端過濾數據報以及客戶端隱藏窗口的方式,降低運行時內存占用數量,增加系統的重用性和可移植性[1]。
2.2 軟件組成及功能
系統軟件由客戶端軟件和服務器端軟件組成(如圖1),客戶端軟件在運行時隱藏窗體,服務器端軟件由監控模塊、登錄模塊、管理模塊、系統設置模塊組成。其中,監控模塊接收和顯示屏幕信息;登錄模塊用于系統啟動時驗證用戶身份;管理模塊用于添加、修改、刪除管理員信息;系統設置模塊用于設置客戶端IP地址。
2.3 數據庫
數據庫主要用于記錄操作員信息和客戶端信息,涉及的數據量較小,可采用Microsoft Access 2003作為后臺數據庫,數據庫命名為db_Supervise,其中包含了2張數據表tb_User、tb_Client。
鑒于系統安全需要,服務器端設置了登錄窗口,在系統啟動時彈出該窗口,讓用戶輸入操作員名稱和密碼,這些操作員的實體信息存儲在表tb_User中;為過濾服務器端接收的數據報,僅接收指定端口發來的數據,需要存儲客戶端IP,將此信息存儲在tb_Client中。
3 客戶端技術
客戶端需要實時抓取本機的屏幕信息,將其分成多個數據報,發送到服務器,為使信息能完整地發送給服務器,客戶端在發送一個數據報后,要等待服務器發來的確認信息,然后繼續發送下一個數據報。這里需解決兩個關鍵問題:一是獲取屏幕信息并轉為位圖格式;二是通過UDP協議將位圖信息發送到服務器。
3.1 屏幕信息轉換
使用Get Desktop Window方法獲取一個屏幕窗口指針,通過該指針獲取屏幕窗口的設備上下文。
CDC*p Desk DC=Get Desktop Window()->Get DC();//獲取桌面畫布對象
定義一個內存畫布對象,將屏幕窗口的設備上下文輸出到位圖中。
根據位圖對象獲取位圖信息。位圖文件由文件頭、信息頭、調色板、位圖數據組成,文件頭包含位圖標記、位圖大小等信息,用BITMAPFILEHEADER結構來描述。信息頭和調色板2個部分描述了位圖的寬度、高度、壓縮、顏色等信息,用BITMAPINFO結構描述[2]。本程序不以位圖文件的形式發送,不發送文件頭。代碼示例:
3.2 位圖信息發送
完成套接字初始化及創建UDP套接字(設置套接字發送緩沖區大小為512)后,調用sendto方法發送數據[3]。
4 服務器端實現
4.1 訪問數據庫類
為方便管理,將數據庫操作封裝在一個類CData Manage中。該類包含ADO Connection對象、ADO Command對象和ADO Recordset對象,并提供Init Database方法用于構造ADO對象、連接數據庫。
4.2 登錄模塊和系統設置模塊
系統啟動時,為驗證用戶身份,需要從數據庫中查詢用戶信息。程序中使用ADO Command對象執行查詢操作。首先需要設置Active Connection屬性,該屬性關聯一個ADO Connection對象,然后設置Command Text屬性,該屬性表示ADO Command對象將要執行的SQL語句。如果SQL語句中有參數,還需要調用Parameters屬性的Append方法插入參數,最后調用ADO Command對象的Execute方法執行SQL語句。代碼演示如下:
系統設置模塊用于過濾接收的數據報,防止接收其他應用程序向服務器的指定端口發送的數據,使用了CIPAddress C-trl控件錄入IP地址,具體實現時先判斷用戶輸入的IP地址是否為空,如果不為空,從數據表中查詢數據,有數據返回時,則修改數據;沒有數據返回則添加數據,以保證數據表中只有一條數據。
4.3 監控模塊
監控模塊完成本系統主要功能的實現,包括實時顯示客戶端傳來的位圖信息,和對抓圖的起始坐標進行有效控制,界面如圖2所示。
添加On Received方法,接收客戶端發來的數據。在數據接收后,向客戶端發送確認信息。其中,對所接收的位圖數據可以調用Show Image方法實現,代碼示例如下:
向客戶端發送控制指令通過添加On Button Down方法實現,其中根據按鈕命令ID的判斷完成對選定坐標軸的設置、緩沖區填充以及數據發送。
除此之外,監控模塊還需完成初始化以及從數據庫中讀取客戶端IP等操作。
4.4 管理模塊
主要實現對系統操作員信息的添加、修改、刪除。為了方便用戶操作,在相應的界面顯示時,會將操作員信息以表格形式顯示出來。這里的表格使用的是MFC提供的CList Ctr類,鑒于外觀設計需要,定義了基于CList Ctrl類的派生類CCustom List Ctrl進行風格擴展,界面如圖3所示。
5 結語
網絡監控的范圍、規模、形式多種多樣。提出的系統開發成本較低,網絡時延小于1秒,運行時占用內存少于10MB,比較適合中小規模網絡的日常管理。另外,系統吸收框架設計理念[4],在功能拓展和界面友好交互方面可以結合網絡特點進行調整,從而最大程度上滿足不同用戶的需求。
摘要：針對多樣化的網絡管理需求,提出一種基于UDP協議的網絡監控系統。介紹了系統的體系結構及功能組成,并分析了軟件設計中主要模塊的關鍵技術和實現機理。測試表明,該系統網絡時延小,內存占用少,具有一定的可擴展性和適用性。
關鍵詞：UDP協議,C/S結構,位圖信息,數據庫
參考文獻
[1]張紅光,溫遇華,徐巧麗,等.面向對象軟件工程[M].北京:機械工業出版社,2003.
[2]明日科技,劉銳寧,梁水,等.VC項目開發案例全程實錄[M].北京:清華大學出版社,2011.
[3]孫鑫,余安萍,編.VC深入詳解[M].北京:電子工業出版社,2006.
udp協議范文第3篇
現在許多病人可以通過互聯網與醫生進行遠程交流，得到醫生的治療和指導。但當需要進一步對病人進行心電監測等身體檢查時，仍然需要病人到醫院現場監測，這對于一些癱瘓，年齡大，離家遠的病人來說，并不是很方便。而遠程在線視頻心電監測系統則可以很好地解決這一問題。通過本系統，病人在家里將監測儀器與電腦連接后，醫生可以一邊對病人進行病情詢問，一邊觀察病人的心電波形情況，更加準確診斷病人病情。
由于網絡寬帶是有限的，為了能夠在遠程醫生端實時地顯示心電圖波形，必須根據心電數據傳輸的特點采用合適的網絡協議和特定的傳輸算法，才能達到滿意的效果。
1 傳輸協議分析
傳輸控制協議TCP和用戶數據報協議UDP是目前傳輸層最常用的兩種協議。
TCP協議在通信前必須建立連接，然后才能傳輸數據。它提供的是面向連接的、可靠的字節流服務，同時TCP還提供超時重發，丟棄重復數據，校驗數據，流量控制等功能。
UDP協議在通信前不需要先建立連接，它提供的是面向事務的、簡單不可靠信息傳送服務，具有資源消耗小，處理速度快的優點。相對于TCP協議來說，UDP協議的傳輸效率較高，并且支持廣播和組播。
心電波形的傳輸和普通文件傳輸是有差異的。前者在一定的范圍內允許存在延遲的現象，為了保證其可靠性，要求有嚴格的差錯控制和重傳機制。后者在傳輸心電波形時，為了保證傳輸的質量，也要求要有差錯控制或者糾錯機制。而且心電波形對實時性的要求較高。若傳輸延遲很大，則會浪費醫生的時間，減少接診病人的數量。若心電波形在傳輸中丟失的數據極少，雖然會導致心電波形發生略微的變化，但對專業醫生來說，并不會影響其對病人病情的診斷。因此相對來說，心電波形傳輸的實時性的要求大于可靠性。
綜合以上考慮，雖然TCP協議可以保證數據傳輸的完整性和可靠性，但對于心電波形數據來說，可能會造成比較大的延遲，并且TCP協議也不支持廣播和組播。而UDP協議在數據傳輸的實時性上更能滿足傳輸心電波形數據的要求，但無法保證傳輸的可靠性。為了使UDP協議可以傳輸心電波形數據，需要根據其傳輸數據的特點，對協議進行一些適當的改進。
2 心電波形傳輸設計
對于心電波形數據的傳輸，需要先在發送端將其分成若干數據包，再由接收端將這些數據包進行重組。如果將數據包分得過大，則發送端IP層會把它包拆分成若干片，接收端IP層相應需要再進行重組，這樣會降低傳輸效率。若將數據包分得過小，雖然可以保證在傳輸的過程中不會被再次拆分，但是這樣會因為數據包的增加，增加了發送的次數，會導致效率的降低。因此，在設計心電波形數據的UDP傳輸時，如何合理地對數據進行分包和如何在接收端正確接收和拼接報文是兩個最重要的問題。
2.1 數據的分包和拼接設計
若數據包之間的大小相差過大，則會導致非常嚴重的傳輸延遲，所以我們將數據進行等分。由于IP層規定的最大傳輸單元為1 500字節，其中IP包頭占20字節，UDP包頭占8字節。同時為了使到達的數據包可以按正確的順序還原，還需要為每個數據包加上一個占4字節的包頭。因此將包的大小定為1468字節。對于長度不足1468字節的數據包，用填充位補齊。如圖1所示。
其中，包頭由包序列號和記錄有效數據長度兩個部分構成。
數據包定義代碼如下:
為了避免因為丟包而導致波形失真，接收端先將收到的數據包存入緩沖區，并按包頭的包序列號進行排序。緩沖區空間的大小需要通過計算公式和具體的網絡狀況進行分配。
假設序列號為Wa的數據包已交給上層處理，當前接收到序列號為Wb的數據包。在理想的情況下，接收到所期望的包的序列號應為(Wa+1)，即Wb=Wa+1。在失序的情況下，則是Wb>Wa+1?，F在假設在未接收到期望的包之前，接收端的緩沖區已經收到了n個平均長度為L的數據包，為了保存這些數據包，則緩沖區的大小至少要為n×L，記為S。
在數據包沒有丟失的前提下，假設由于數據包延遲產生失序情況，Wb數據包恰好在第x個數據包到達的概率為Px(即延遲x-1個包到達)。每個數據包丟失的平均概率為P1，令A表示Wb數據包恰好在Wb+x到達，B表示數據包丟失事件，根據全概率公式:
其中P(B/A)=0，而P(B')=1-P1，而且Wb數據包恰好在Wb+x到達時緩沖區內僅存放x-1個數據包。根據數學期望的定義，隨機變量N的平均值為:
所以緩沖區的大小S為:1472×E(N)。為了使系統性能達到最優，考慮到現實網絡的具體情況，根據接收到數據包的丟失和失序情況的統計結果，緩沖區的實際大小應該比由式(1)計算得到的S值略大一些。
2.2 丟失和重傳處理機制
在保證數據傳輸的可靠性時，為了避免因為可靠性而導致數據傳輸延遲過大，從而影響數據傳輸的實時性，因此這里的應答機制和超時處理機制是最大程度上保證數據的不丟失。處理方法基本實現步驟如下:
首先在發送端和接收端根據上述的算法和實際的網絡環境，分別分配一個可容納n個數據包的緩沖區S。
(1)接收端把接收到的數據包放入到緩沖區中，若緩沖區在收到n-1個包之前等到了期望的數據包，則整合該包，并向發送端發送確認信息，然后將該包提交給上一層進行處理，接著在緩沖區查找下一個期望包。確認信息結構如圖2所示。
(2)發送端在接收到步驟(1)的確認信息后，則在發送端的緩沖區中刪除所有小于期望下一個包的序列號的數據包，填充新的數據包到緩沖區里。
(3)若接收端的緩沖區在接收到n-1個包時沒有等到期望的包，則停止接收新的數據包。然后向發送端重新發送請求該期望包的信息，同時啟動接收定時器。若定時器時間到后，還未接收到期望的數據包，接收端則再次發送請求信息。重復一定次數后，還未收到期望的包，關閉定時器，放棄請求。直接在緩沖區中查找下一個期望的數據包，并向發送端發送確認信息。當接收端接收到小于期望序列號的數據包時，直接丟棄掉。
(4)當發送端的緩沖區填滿數據包，但未有確認信息的回復，則啟動發送定時器，再次發送期望的數據包。重復一定次數后，仍未收到確認信息，則表示當前網絡不通或擁塞嚴重，放棄向接收端發送數據，并向用戶發出相應的提示，建議選擇其他時間進行在線心電監測。
具體實現流程如圖3所示，假設當前已送上層處理的數據包的序列號為Wa，當前接收到的包序列號為Wb。
3 實驗結果
為了驗證上述算法的可行性和有效性，分別用TCP協議、未改進的UDP協議和已改進的UDP協議進行實驗測試。通信網絡為電信的8 MB寬帶，每個協議在線測20 min的心電，各測30次。
圖4中，最上面的一條曲線，是采用未經改進的UDP協議進行傳輸，幾乎沒有延時，但可以明顯地看出總體丟包率很大;中間的一條虛曲線，是采用改進的UDP協議進行傳輸，總體丟包率很小，延時也很小;最下面的一條曲線，是采用TCP協議進行傳輸，總體丟包率最小，但延時很大。
通過上述數據對比分析，使用改進后的UDP協議可以滿足在線心電波形數據傳輸的實時性和可靠性的要求。如圖5所示。
4 結語
本技術已經在實際項目中得到了應用，并取得了良好的效果。本文根據心電波形數據傳輸的要求，對UDP傳輸協議進行了一些改進，通過對數據進行合理分包和對無序到達的數據包的接收的研究，彌補了UDP在數據傳輸可靠性方面的缺陷，提高了數據的傳輸效率。
摘要：由于心電圖波形數據在計算機網絡中傳輸對實時性和可靠性的要求都比較高,而目前網絡傳輸層中常用的TCP協議和UDP協議均不能滿足此要求。針對這種情況,提出一種對UDP協議進行改進的方法。通過對UDP協議的通信特點的分析,設計了一種實現簡單、效率高的分包和拼接方法,添加了失序、包丟失和超時處理機制。實驗結果表明,心電圖波形數據利用改進后的UDP協議進行傳輸,可以滿足其數據傳輸的要求。
關鍵詞：UDP,實時性,可靠性
參考文獻
[1]程小恩.UDP協議在FTP服務中的應用[J].計算機光盤軟件與應用,2014(3):97-99.
[2]紀凌,李怡謙.基于RTP協議流媒體識別算法的設計及實現分析[J].計算機安全,2014(2):11-13.
[3]劉斐,崔丹丹.基于改進UDP網絡協議的物流實時視頻數據遠程傳遞系統設計[J].物流技術,2014(9):446-449.
[4]彭國文.UDP協議實現點對點高速可靠傳輸模型[D].中山大學,2013.
[5]李世其,王長安,朱文革,等.基于UDP的遙操作數據傳輸可靠性保證[J].自動化與儀器儀表,2013(1):142-145.
[6]白正,柳登豐,孫文俊.基于UDP的報文可靠傳輸技術研究[J].網絡安全技術與應用,2013(5):34-36.
[7]趙飛,葉震.UDP協議與TCP協議的對比分析與可靠性改進[J].計算機技術與發展,2006(9):219-221.
[8]王宇聰,韓啟祥,蔡惠智.聲納信號處理中UDP協議數據傳輸研究與設計[J].現代電子技術,2012(1):78-79,84.
udp協議范文第4篇
關鍵詞：UDP協議,局域網授時,正則表達式
1 引言
在很多單位,為了實現信息安全保密,往往僅允許部分計算機連接互聯網,單位辦公、財務等信息系統自成一個局域網,與互聯網物理隔離,這時局域網內的計算機就無法通過互聯網的授時系統自動獲得準確的天文時間,而有些時候又需要對局域網內的所有計算機進行統一時間設置,這就需要用到授時系統。介紹了一個簡單的基于UDP協議的授時系統的實現,用以對局域網內部計算機進行授時操作。用戶通過手工或一定的接口(RS232等)將從互聯網、GPS授時系統或者北斗授時系統等獲取的準確的天文時間輸入授時服務器,而后由服務器自動向局域網內安裝了授時客戶端的計算機提供授時服務。
系統選用使用簡單、網絡帶寬消耗小的UDP協議,保證了局域網范圍內的較小延時,提高了系統的時效性。
2 系統設計
該系統由授時服務器和授時客戶端兩部分組成。
2.1 系統應用結構
如圖1所示,系統分為授時服務器和授時客戶端兩部分,二者通過UDP協議溝通傳輸時間信息,對系統時間進行校正。
2.2 關鍵技術
本系統使用C#語言提供的UDPClient類實現UDP協議數據報的接收和發送,使用Dll Import Attribute方法引入設置系統時間的API函數,使用正則表達式實現IP地址格式的校驗。通過使用這些技術,提高了系統的靈活性、易用性和健壯性。
2.2.1 UDP協議的優點
UDP協議是一種簡單的、面向數據報的無連接協議,提供了快速但不一定可靠的傳輸服務。它的優點是無連接(速度快)、網絡帶寬消耗小、有消息邊界。此處使用UDP協議有利于減少網絡時延對授時準確性的影響,保證系統有較高的時效性。
2.2.2 使用Dll Import Attribute引用外部API
設置系統時間需要調用WIN32 API函數,C#提供了Dll Import Attribute方法用來引入動態鏈接庫的接口函數。此處引入了“Kernel32.dll”庫,引用了其“Set Local Time”函數,用于校正本地時間。
2.2.3 使用正則表達式實現IP地址輸入的校驗
對于IP地址的輸入,有固定的限制,即4個域需用“.”分隔,每個域數值不得超過255,可以通過使用IP地址文本框或者正則表達式的方式實現,為簡化程序,使用了如下所示的正則表達式實現輸入IP地址的合法性檢驗。
2.3 系統實現
2.3.1 服務端
授時服務器通過手工或一定的接口(RS232等)獲取到準確的天文時間,校正服務器的系統時間,按客戶請求向客戶端發送時間。
2.3.2 客戶端
授時客戶端向服務器報告客戶端的授時請求,向服務器提供監聽端口,等待接收服務器的授時信息,收到授時數據后對客戶端本地時間進行校正。
3 代碼實現
3.1 服務端代碼
3.2 客戶端代碼
3.3 系統運行界面
系統服務端和客戶端運行界面如圖2所示。
4 結語
udp協議范文第5篇
中石油油氣生產物聯網項目是由數據采集子系統、數據傳輸子系統、生產管理子系統組成。井場采集的生產數據需要通過傳輸網絡傳至上位機組態系統, 多數情況下應用Modbus/TCP協議來作為RTU到上位機組態通訊。然而在大慶油田的實際推廣應用中, 采用無線Mc Will網絡作為數據傳輸通道, 由于在實際中給分配利用的頻寬較小, 生產現場單井分布十分密集, 同時Mc Will網絡單基站最大并發連接數有限;如果應用TCP協議, 因TCP協議需要“三次握手”機制建立連接, 同時TCP協議要不斷地維護連接, 占用無線信道資源較大, 傳輸耗時較長, 勢必給現有無線網絡造成很大的負擔甚至會造成網絡故障, 因此提出應用Modbus/UDP協議完成RTU到上位機組態系統通訊, 從而來改善無線網絡壓力。
二、Modbus/UDP協議格式設計
1. Modbus/UDP幀結構設計。
目前Modbus/TCP協議沒有相應行業標準, 根據《油氣生產物聯網建設規范》及實際情況的需要, 針對Modbus/TCP協議幀結構進行相應調整改動, 設計出Modbus/UDP協議格式, 如表下表:
數據標記:Bit7-Bit6:數據收發Bit5:0 Bit4:功圖相關報文Bit3:歷史
功圖數據標識bit2-bit0:modbus的數據類型;起地址:數據的起地址;數據
長度:要上傳或讀取的數據長度;油井ID:CRC-32計算得到, 使用GB2312編碼;
數據校驗和:后邊數據包的CRC16校驗和;數據包:數據表中的數據塊。
2. 通訊連接機制。
由RTU主動連接上位機, 發送連接請求, 發送的數據包為心跳包。然后上位機把當前的時間返回給RTU, RTU收到應答后, 標記通信正常;上位機應答心跳包之前RTU 10s發送一個數據包;上位機應答心跳后RTU三分鐘發送一個心跳包。
3. 可靠性保證, 應答超時機制。上位機給RTU發送數
據請求時, 因某種原因RTU未能及時應答, 產生采集超時?？紤]無線網絡情況, 超時時間暫設置為10s, 當上位機發送數據采集請求命令后10s沒有收RTU應答, 重新發送第二次請求, 第二次請求10s后沒有收到應答發送第三次請求, 第三次請求10s后未能收到RTU應答, 本次數據采集失敗, 設備轉為故障狀態。故障狀態等待一定時間后, 重新發送請求。
三、Modbus/UDP協議在數字油田中實際應用
1. 部署連接:
通過在井場中安裝部署RTU設備、壓力變送器、電量采集模塊、一體化示功儀、在組態服務其上部署上位機軟件系統, 通過Mc Will無線網絡將RTU采集的實時數據, 傳送到上位機組態系統, 進行實際測試應用。
2. 程序開發:
分別按照協議規定的結構和通訊機制, 對RTU進行驅動程序開發、對上位機組態系統進行接口程序開發。
3. 實際運行及效果分析:
通過在上位機組態軟件系統上長時間進行監控, 上位機能夠順利的與RTU通過Mc Will無線網絡在Modbus/UDP協議下進行通訊, 上位能夠正確接收現場實時數據, 通信情況比較穩定, 整體效果良好。Modbus/TCP協議的可靠性由TCP協議保證, TCP通信是面向連接的, 通信雙方通過發送確認的方式保證數據正確無誤的傳輸。Modbus/UDP協議可靠性通過應用層協議實現, MODBUS協議是一種請求/應答方式的協議, 也就是如果沒有請求, 服務器端不自動返回數據, 同時通過設計心跳、超時重傳機制保證了通信的確定性和可靠性。UDP協議最大的避免了TCP的延遲問題, 沒有三次握手機制, 不用不停的維護建立的連接, 從而快速的傳遞數據, 減少了傳輸耗時。
四、結束語
本文首先介紹Modbus/UDP協議提出, 對其協議格式進行設計, 然后在一個項目的基礎上對該協議實現并進行應用測試, 最后從實際運行效果以及可靠性、延遲方面對該協議進行分析。采用UDP發送Modbus數據幀, 協議簡單、效果好。相比于Modbus/TCP協議, 這種改進無需進行連接的建立、維護和斷開, 可以極大地提高系統的實時性, 安全性和可靠性得到增強, 有很好的應用前景。
摘要：在中石油油氣生產物聯網項目實際的建設過程中, 遇到了Modbus/TCP在2G/3G/Mc Will無線網絡環境下應用的問題, 因現場無線網絡可應用頻率資源有限, 基站最大并發連接數有限, 在應用TCP傳輸層協議就顯得捉襟見肘, 進而提出了應用UDP協議構建傳輸層協議, 形成Modbus/UDP協議框架。通過對Modbus/UDP協議的研究以及進行實際應用, 良好地驗證了這個協議的應用是可行的、穩定的、效率高的。
udp協議范文第6篇
當突發災害發生的時候, 常規的地面通信設備或者系統就會遭到嚴重破壞, 衛星應急通信系統將能夠確保關鍵信息的傳輸, 使上級能夠根據災情進行有效的指揮, 從而拯救更多的生命和財產。衛星應急通信的特點是:具有開通時間短、傳輸距離遠、通信容量較大、網絡部署快、組網方式靈活、可以實現數據的雙向傳輸。衛星應急通信系統如圖1所示。
二、基于UDP協議的衛星用戶地面站維護平臺的設計
2.1 需求分析
本課題主要針對衛星應急通信的特點來設計維護平臺。當地震導致常規地面通信遭到嚴重破壞時, 可以把衛星用戶地面站拿過來, 作為與衛星通信的交換機, 這里就需要一個維護臺來配置這個衛星用戶地面站, 讓其快速的進入工作狀態, 例如對槽號、話路號的優先級、衛星呼出權、CO中繼權、會議召集權等參數的快速配置, 從而確保關鍵信息的及時傳輸。
2.2 接口要求
衛星用戶地面站和維護臺之間通過TCP/IP協議通信, 物理層采用以太網接口。UDP協議作為傳輸協議, 消息數據作為UDP的凈荷。
2.3 基本功能
配置管理功能:完成用戶屬性、會議和衛星模塊的配置功能, 并具備配置數據單獨文件生成和加載功能;狀態監控:監視用戶站的各種工作狀態, 并能完成對用戶站的自檢和自檢結果處理功能;計費功能:完成呼叫記錄的獲取、存儲、檢索和計費功能;配置數據導出功能:完成從用戶站配置獲取數據, 并具有配置數據單獨生成配置文件功能;多用戶站管理:維護臺能夠管理多個用戶站, 根據用戶站ID選擇對應的數據, 但同一時刻只管理一個用戶站。
2.4 通信協議的格式
消息的組成如表1所示, 每條消息以數據幀的格式采用FLAG封裝, 每一條消息以標志字符 (FLAG) 開始和結束, A字段為鏈路層凈荷的長度, C字段為一個序號, 用于完成消息的可靠傳輸。CRC字段是一個循環冗余的檢驗碼, 以檢測數據幀中的錯誤。
三、衛星用戶地面站與維護臺的可靠通信流程
3.1 識別
因為UDP協議本身是面向無連接的, 而本協議中加入的識別機制則解決了這一不可靠因素, 使連接更快速, 更有目的性。本過程完成通信雙方之間的識別, 獲得雙方的IP地址。通信采用廣播 (廣播地址為255.255.255.255) 形式。目的地址均為廣播地址, 源地址為發送方的IP地址。識別過程如下圖2。
3.2 雙線程
維護平臺后臺啟用兩個線程, 分為控制線程與數據線程。采用雙線程機制, 即兩個線程采用不同的容錯策略?？刂凭€程在成功進行握手后便由數據線程來接手數據的傳輸, 中間還需要數據端口發送鏈路?；钕? 直至數據傳輸結束, 整個過程中的所有檢測消息和數據傳輸均采用表1所描述的消息結構。
3.3 鏈路通斷檢測
使用Keep-Alive?；钕? 用于鏈路的通斷檢測。?；钚畔⒓皵祿⑹瞻l所用端口為:初始化收發序號均為0, 狀態均為DOWN, KEEP_ALIVE的周期為3秒, 連續3次KEEP_ALIVE發送后, 對方無響應認為鏈路DOWN, 并且清除隊列, 暫停?；疃〞r、等待新的連接, 否則發送新的?；顖笪?。
3.4 停等待機制
鏈路在UP狀態下, 采用改進的停等待機制。此機制能保證消息傳送的有序、不重復、防丟包, 使接收方收到準確無誤的消息。發送時在沒有收到響應消息前, 不能進行下一條消息發送, 。接收時對于相同序號的消息只處理第一次條, 其它的只進行確認響應。通信雙方各自維護自己的序號C字段, 范圍為0~127循環, 接收到消息并確認正確后, 將序號C字段的第7位置為1, 組成響應幀發送給對方, 并記錄當前接收的對端序號C字段的值, 如果再次收到同樣序號C字段的消息只進行響應而不處理。
四、維護臺界面的測試
4.1 識別
維護平臺上加入識別連接界面, 進行與衛星用戶地面站的數據通信, 能達到快速識別, 以便于對其進行快速配置。利用本維護平臺目前能達到快速識別和連接到衛星用戶地面站。點擊搜索按鈕, 客戶端會發出廣播消息, 用戶站收到此消息后會給出響應消息, 然后客戶端通過對收到的響應消息進行分析, 得到用戶站的IP地址和設備ID號, 并顯示在窗體中。如圖3所示。
4.2 ?；?/p>
點擊連接按鈕, 則線程回歸到主窗體中, 主窗體上的信息欄會顯示“連接到用戶站:121.193.211.138”。如果連接中間出現斷開情況, 則信息欄會給出“失去與用戶站 (121.193.211.138) 的聯系, 請重新進行設備識別”的提示, 客戶機應進行設備的重新識別和通信連接的建立。
4.3 維護臺功能模塊的實現
維護臺通過以太網連接于用戶站連接, 通過發送廣播包搜索設備, 等1秒后, 確認是否有連接的用戶站, 如果有多個用戶站響應, 選擇一個作為當前設備, 根據匯報的設備ID, 選擇其對應的數據庫進行工作。
五、結論
對于衛星用戶地面站和維護臺之間的可靠通信, 本文加入了一些機制, 使可靠性得到了保證。對于維護臺的設計以簡單、實用為原則, 實現其要求的基本功能, 能夠實現快速投入使用、快速配置衛星用戶地面站。隨著問題研究的深入, 在數據傳輸過程中, 速率和可靠性之間存在的矛盾將是接下來要解決的問題。
摘要：衛星用戶地面站作為衛星應急通信設備具有使用方便、組網靈活的特點。本文針對這些特點設計出了具有快速配置、可靠傳輸的維護平臺。文中介紹了衛星用戶地面站維護平臺的接口、基本功能、通信協議以及通信流程。
關鍵詞：衛星應急通信,維護臺,UDP,可靠通信
參考文獻
[1]王毳.衛星數據接收站中網絡協議的應用.中國電子科技集團公司第五十四研究所, 2009, 39 (4) :50-52.