前言：中文期刊網精心挑選了udp協議范文供你參考和學習，希望我們的參考范文能激發你的文章創作靈感，歡迎閱讀。

udp協議范文1

關鍵詞:通信網絡;基于樣本塊的方法;udp協議;Mean-Shift方法

中圖分類號:TP311文獻標識碼:A文章編號:1009-3044(2010)21-5714-02

通信網絡為計算機信息的獲取、傳輸、處理、利用和共享提供一個安全可靠的環境和傳輸通道,但現實中通信網絡并非是絕對安全的,傳輸數據過程中數據包的丟失、泄密和篡改時有發生,且日趨嚴重。

目前在通信網絡中比較常用的兩個通信協議是TCP協議和UDP協議。TCP是一種面向連接的協議,采用“三次握手”方式來確保數據的準確接收,其工作機制是首先是建立連接;其次發送端發送數據,接收端接收數據;再次接收端向發送端發送反饋信息,如果發送數據被成功接收,則斷開連接,否則必須重傳發送失敗的數據。而UDP協議是一種無連接的協議,不提供可靠的信息發送機制,因此在數據傳輸過程當中更容易出現數據包的丟失現象。

TCP協議雖說提供安全的數據傳輸,但是傳輸效率不高,因此不適合于實時性較高的應用。UDP協議雖說不提供安全的數據傳輸,但是其傳輸效率很高,能實現實時傳輸,但是容易出現丟失數據包的問題。在實際當中很多實時性很高的珍貴數據是不容有失的,那么如何解決這一問題呢?

在2003年Shantanu D.Rane等提出無線電傳輸中丟失數據復原的問題,他們結合現有的圖像修復技術和紋理合成技術對傳輸過程中丟失的數據進行填充。在傳輸過程中,圖像被劃分為 的塊,計算其離散余弦變換,然后量化并進行哈弗曼編碼,最后傳輸圖像數據[1]。該文獻中對丟失數據填充過程如下:對丟失的塊分類,根據周圍的塊判斷丟失塊是紋理塊還是結構塊,如果是紋理塊使用紋理合成算法,否則使用結構修復算法。分析發現該方法對于塊的分類不夠準確,而且丟失數據的填充比較耗時。

本文針對上述缺陷直接使用基于樣本塊的方法[3]填充UDP協議丟包數據。在目前所有的圖像修復方法中,基于樣本塊的修復方法是非常有效用的一種,它不僅能夠填充圖像紋理部分,而且能夠修復圖像簡單的結構,對結構的修復主要是受修復的優先權和樣本塊的大小控制,適合的修復順序和樣本塊大小是有利于圖像結構的保持。因此本文直接使用基于樣本塊的方法對丟失的圖像數據進行填充,這樣不僅能夠提高填充的效率,而且能夠減輕數據包的丟失造成嚴重損失。

1 基于樣本塊的丟失圖像數據填充

UDP協議的數據傳輸過程與無線電數據的傳輸是相似的,其優點是傳輸過程中的部分數據丟失不會引起整個圖像數據的混亂,這就為數據的恢復提供了一定的可能,否則數據的恢復是非常困難的。在很多文獻中提到UDP協議的丟包率與具體網絡環境有關,沒有一個準確的數值,但是一般來說其平均丟包率總會小于無線電數據的丟包率3.6%[2]。

基于樣本塊的方法一種非常有效的丟失圖像數據的填充方法,它不僅能填充大塊的紋理破損,而且能夠修復較小的結構破損。UDP協議的丟包率一般來說很小,這也就為圖像的結構部分的復原提供了重要的保障?；跇颖緣K的圖像修復過程如下:

1) 確定丟失數據包的位置,因為圖像數據是經過編碼后傳輸的,因此即使丟包也不會使得整個圖像數據混亂,自然其丟失數據的位置容易確定;

2) 尋找破損區域的邊緣;

3) 按照優先權計算方法確定當前優先權最高的像素點,優先權P(p)一般為信任度因子C(p)與數據因子D(p)的積。信任度因子和數據因子的計算如式(1)和式(2):

(1)

(2)

信任度因子確保了當前待修復塊上有更多的已知像素點來確保找到的最佳匹配塊的準確性,而數據因子表示破損區域邊界在優先權最高像素點處的法線與該點處等照線的夾角,夾角越大則結構越強,否則結構越弱,結構越強的自然越先修復,這樣有利于圖像邊緣的保持;

4) 根據相似度的度量機制,尋找最佳匹配塊;

5) 將最佳匹配塊中的數據拷貝到當前待修復塊中,注意只拷貝當前塊中破損像素點對應的數據;

6) 更新破損區域;

7) 判斷破損像素點的個數是否為0,如果為0,則轉8),否則返回到2);

8) 修復結束。

基于樣本塊的修復方法雖說有很好的修復效果,但是也必須注意其修復過程中存在的問題。首先誤差的累積問題,這必然導致錯誤的填充結果。其次是最佳匹配塊的選擇問題,如何在多個候選最佳匹配塊中選出真正最佳的匹配塊。

文獻[4]提出一種新的方法來解決這誤差累積的問題,首先使用Mean-Shift方法[5]對圖像進行了粗劃分,對最佳匹配塊的選擇區域作了限制,具體的最佳匹配塊的選擇原則如下:

1) 如果待修復塊屬于粗劃分Ti,則最佳匹配塊僅在Ti中選擇;

2) 如果待修復塊處于多個劃分Ti∪Ti+1∪...∪Ti+k的邊緣,則最佳匹配塊在Ti∪Ti+1∪...∪Ti+k中選擇。

上述方法相當于給匹配塊的選擇加了一些約束,使選擇范圍縮小。這樣不僅縮短了尋找匹配塊的時間,也避免了誤差的累積。

另外一個問題就是最佳匹配塊唯一的問題。假設目前找到的匹配塊為ψp1, ψp2,…ψpk,那么如何在這之中選擇一個真正的最佳匹配塊。文獻[6]提到了一種選取最佳匹配塊的方法,認為與當前待修復塊的空間距離越近,其相關程度越高。因此,通過計算待修復塊的核與匹配塊的核之間的空間距離來最終選定哪個塊是真正的最佳匹配塊。丟失數據的填充流程圖如圖1所示。

2 實驗結果

本文用VC++實現了該算法,通過大量的實驗說明了本文算法的有效性。由于傳輸圖像很容易獲得,因此本文采用峰值信噪比的方法對恢復結果進行客觀評價。峰值信噪比PSNR的計算如下式:

(3)

PSNR值越大,恢復的效果越好,越接近原圖;PSNR值越小,恢復效果越差,與原圖差異越大?；謴徒Y果如圖2、圖3、圖4所示。

4 結論

本文分析了通信網絡中UDP協議的傳輸機制,發現UDP協議在傳輸數據時容易發生數據丟包問題,由此使用基于樣本塊的方法解決恢復丟失數據包的問題。盡管文獻[1]的作者提出了無線傳輸中圖像數據的恢復方法,但是該方法比較復雜,而且存在諸多的不穩定性,諸如塊的分類等。本文結合基于樣本塊修復的優點對丟失數據進行恢復,并通過實驗進行了驗證,確實取得了令人滿意的效果。這樣不僅很大程度上提高了UDP協議圖像數據傳輸的安全性,也提高了UDP協議的傳輸效率。

參考文獻:

[1] Shantanu D.Rane,Guilloermo Sapiro and Marcelo Bertalmio. Structure and Texture Filling-in of Missing Image Blocks in Wireless Transmission and Compression Applications[J].IEEE TRANSACTIONS ON IMAGE PROCESSING,VOL.12,NO.3,MARCH 2003,pp.296-303.

[2] E.Chang. An image coding and reconstruction scheme for mobile computing.In proc.5th IDMS,Oslo,Norway,Sept.1998,pp.137-148.

[3] A.Criminisi,P.Perez and K.Toyama. Region Filling and Object Removal by Exemplar-Based Image Inpainting[J].IEEE TRANSACTIONS ON IMAGE PROCESSING,VOL.13,NO.9,SEP 2004.

[4] Feng Tang,Yiting Ying,Jin Wang,and Qunsheng Peng.A Novel Texture Synthesis Based Algorithm for Object Removal in Photographs. MJ Maher (Ed.): ASIAN 2004, LNCS 3321, pp. 248C258, 2004.

[5] Comaniciu D, Meer P.: Mean Shift: A Robust Approach toward Feature Space Analysis[J],IEEE Trans. Pattern Analysis Machine Intell,Vol.24, No.5,603-619,2002.

udp協議范文2

關鍵詞：arm；linux；交叉編譯環境；udp協議；重發機制；重發次數

udp協議以其高效性和應用的簡單，被廣泛運用于嵌入式網絡開發中。由于udp協議的應用簡單，在嵌入式設備開發過程中，網絡資源的利用率并不高。以下將介紹一個udp具體項目實驗過程，描述arm-linux環境的軟硬件環境構建過程，并對udp協議下一種重發模式中上位機的重發次數的確定提出一種可行的方法。

1 研究背景

隨著嵌入式技術的快速發展，嵌入式設備已經在許多領域取代了傳統的微型機設備。本文的選題主要來自于實習期間承接的一項改造項目：某院校特長生評分系統的改造。項目改造目的有：1) 保留原上位機。2) 改用手持式客戶端進行顯示及評分操作。3)保留原有網絡設備。針對要求，我們使用s3c2440作為硬件平臺，移植linux操作系統，并在arm-linux環境下研究了udp協議的通信過程，進行了上位機與嵌入式系統的udp協議通信實驗及分析，并給出一種重發機制中的發送次數求法。

2 硬件平臺介紹

s3c2440處理速度達到了400mhz，具有較高的性價比。為了提高開發效率，我們采用公司自行研制開發的et-s3c2440開發板。

2.1 et-s3c2440開發板簡介

et-s3c2440是公司自行開發的一款arm9架構的實驗開發板，其結構框圖如圖1。

核心板的主要器件有：32mb×2片sdram，64mb norflash，512mb nandflash。設計了啟動方式可選，通過開關選擇從nandflash或norflash啟動。

2.2 實驗相關電路說明

底板電路主要功能是輸入輸出以及網絡通訊功能。按鍵輸入部分采用掃描方式獲得輸入，用一個單向地址鎖存器和一個雙向地址鎖存器與地址總線相連，可以通過掃描地址來獲得按鍵輸入。lcd采用三星的3.5寸tft屏作為顯示輸出設備。網卡芯片選用的是與原設備匹配的10m 的cs8900a，關于cs8900a與s3c2440的硬件連接，有眾多資源可供參考，本文不再贅述。

3 系統軟件平臺的構建

硬件平臺搭建完畢后要將操作系統和應用程序在硬件平臺上運行起來。以下是對嵌入式linux操作系統移植的過程。

3.1 交叉編譯環境的構建

linux 2.6.29.1版本的內核可以登錄到下載。本文選擇的是arm-linux-gcc-4.3.2工具鏈()

在宿主機上進入linux系統，切換當前目錄到工具鏈所在目錄，新建一個arm目錄保存解壓后的文件(mkdir /user/local/arm)并將arm-linux-gcc-4.3.2解壓到這個目錄中(tar jxvf arm-linux-gcc-4.3.2 –c /user/local/arm)。然后將環境變量$path修改一下，讓$path中包含有arm-linux-gcc所在的目錄(編輯/etc/profile 添加語句”export path=/user/local/arm/4.3.2/bin:$path”)，然后reboot一下，這樣交叉編譯環境就構建好了。

3.2 bootloader的移植

vivi是一款相當成熟和相對簡單的常用bootloader，我們以vivi為移植原型，將s3c2440所有io端口寄存器定義添加到頭文件2440add.inc，刪除部分硬件平臺使用不到的代碼，最后將修改過的vivi制作成鏡像燒錄到flash中。[1]

3.3 linux內核移植

獲取linux-2.6.29.1源代碼并解壓后，首先修改內核源代碼所在目錄中的makefile，將系統架構修改為arm(arch ?=arm ),交叉編譯工具修改為arm-linux-gcc (cross_compile ?=arm-linux-)，修改輸入時鐘(arch/arm/mach-s3c2440/mach-smdk2440.c中的函數static void __init smdk2440_map_io中，修改s3c24xx_init_clocks(12000000)此處所用晶振為12m)。修改machine名稱(在arch/arm/mach-s3c2440/mach-smdk2440.c文件中的函數machine_start( ),修改為machine_start(s3c2440, “自定義機器名”)，修改nandflash分區信息(arch/arm/plat-s3c24xx/common-smdk.c結構體static struct mtd_partition smdk_default_nand_part[]中保存的是nandflah的分區信息，將其修改為當前使用的分區信息),然后修改nandflash的匹配時間(3c2410_platform_nand_smdk_nand_info smdk_nand_info ={})。

上述內核源代碼修改完成后，還需要對一些設備的驅動進行修改。本文使用的nec 3.5寸 320×240液晶屏，硬件平臺使用gpg4腳進行背光控制，需要修改lcd背光(/arch/arm/mach-s3c2440/mach-smdk2440.c中static void __init smdk2440_machine_init(void)，將函數中的gpio口配置為gpg4)。關于cs8900a網卡的驅動移植，相關資源很豐富，本文也不再贅述。

本實驗中nandflash采用的是yaffs2文件系統，所以打yaffs2文件系統補丁，壓縮包為cvs-root.tar.gz。

至此，linux的內核源代碼修改工作完成了，下面還需要利用makefile,進行內核配置。

在linux 2.6.29.1內核目錄下首先make s3c2410_defconfig使用2410的配置模板來配置2440；然后make menuconfig,這時我們可以在圖形化界面中，空格鍵可改變各個配置選項的被選中狀態，根據需要進行配置即可。配置完成后保存好配置，最后進行內核的編譯(make dep 建立文件間依賴 make clean 清除編譯殘留文件make zimage 生成內核壓縮鏡像文件)。

編譯過程完成后會在內核目錄arch/arm/boot/下生成zimage內核映像文件，將這個鏡像文件燒錄到flash中，調試檢驗，經上述修改后的內核工作運行正常。

3.4 根文件系統的制作

根文件系統是使用busybox-1.13.3來制作完成。下載busybox并解壓完成后，修改makefile中的架構為arm架構，編譯工具為arm-linux-gcc( arch ?=arm； cross_compile ?=arm-linux-),然后make menuconfig,通過圖形界面對busybox進行配置，然后對busybox進行編譯(make config_prefix=/opt/studyarm/rootfs install)，在目標目錄下會生成目錄bin、sbin、usr和文件linuxrc的內容。

基本目錄結構生成后，應該在目標目錄下建立一些未生成的必要的系統目錄如dev、etc、lib等，并通過chmod命令改變目錄權限為可寫。再將一些必要的動態鏈接庫和靜態庫拷貝到lib下，然后在dev目錄下創建設備節點，最后創建該嵌入式linux系統的初始化配置文件(包括設備列表文件、口令、網絡分組組名、hostname主機名、etc/inittab初始化表單、etc/profile環境變量配置文件、用于系統初始化的.bash腳本文件等)。由于本實驗需對網絡編程，要求自動初始化cs8900a網卡芯片的ip地址、網關、子網掩碼等，所以在開機自啟動腳本中加入ifconfig語句，使得開機時自動配置網卡參數。

根文件系統構建完成后，使用yaffs2文件系統制作工具mkyaffs2image.tgz，通過命令mkyaffs2image rootfs rootfs.img生成根文件系統鏡像，然后將鏡像燒寫入flash中。

4 arm-linux環境下的udp協議通信實驗

經過上述硬件設計和操作系統移植過程，本文所使用到的實驗環境已經構建完畢，經反復調試修改，嵌入式linux操作系統在平臺下運行正常，于是進行udp協議通信實驗。

4.1 udp協議套接字編程基礎

udp是一個面向數據報和無連接的簡單傳輸層協議，它不像tcp那樣通過握手過程建立服務器與客戶端的連接才可以工作。在網絡通信質量較好的情況下，udp體現出高效率，這適合于傳送少量報文的應用。 linux系統是通過套接字結構來進行網絡編程的，應用程序通過對套接字的幾個函數調用，會返回一個用于通信的套接字描述符,而linux應用程序在進行任何形式的i/o操作時，程序實際上是在讀寫一個文件描述符。因此linux下的套接字編程，可以看成是對普通文件描述符的操作，這些操作與被使用的硬件平臺無關，這是linux設備無關性的優點。udp協議的通信模型如圖3所示。

在上述流程中，客戶端所收到的報文被存儲在緩沖區中，recvfrom()函數返回了報文存儲緩沖區的首地址，我們可以很方便地對這個首地址進行數組操作，從而實現對報文的解碼。

4.2 上位機報文結構及重發機制分析

根據項目要求，上位機軟件依然保留，我們使用協議嗅探工具對上位機發送的報文進行了嗅探，得到了上位機報文的結構如表1所示。

表1 上位機報文結構

上位機發出的每條報文由32個字節組成，第0位為版本信息。第1……12位為比賽信息和運動員教練信息，是報文的關鍵信息部分，13……22位為服務器端和客戶端的ip地址及端口號信息，23位是上位機對客戶端的操作指令代碼，24位是相關重發機制的代碼，30和31兩位是checksum，用來保證數據傳輸的正確。上位機采用的重發機制是一種上位機按照固定重發次數多次發送同一關鍵內容報文的機制，其第24位重發機制位被分為高4位和低4位兩部分，高四位的內容是當前發送的報文的索引號，每次發送一條新內容的報文時索引號自增1，索引號的取值范圍在0x00—0xff范圍內循環自增。低四位是重發編號，表示同一索引號的報文正在被第幾次重發，固定的重發次數由上位機初始化時設定。

4.3 嵌入式客戶端的實驗程序設計

針對報文結構，我們對接收端編寫實驗程序代碼，代碼的主要功能是從上位機接收報文，將計算出的checksum校驗和與收到的校驗和對比判斷報文是否正確，然后從正確報文中取出主要信息并按照報文中的上位機指令碼進行輸出。其結構流程圖如圖3所示。

實驗程序經編碼、調試后在交叉編譯環境中交叉編譯，生成arm-linux環境下可執行文件，在目標板上執行。經測試試驗程序能夠正確接收上位機發來的報文，對報文解碼，并能根據上位機命令對關鍵信息做輸出處理。

4.4 對上位機重發次數的研究

進行udp協議通信時，發送端和接收端的狀態是相對獨立的，發送端不與接收端建立連接，而是不停向接收端發送，為了確保不丟失報文，上位機采取了按固定次數重發相同內容報文的機制。然而這種機制雖然可以有效確保報文不丟失，但是大量冗余數據報被發送，網絡資源利用率不高。重發次數越多，冗余數據報越多，效率越低。要想有效保證數據報準確發送的同時又不產生過多冗余數據報，那么重復發送的次數的確定就成為問題的關鍵。以下給出一種確定上位機重發次數的方法。

假設當前網絡狀況下，每次報文發送被丟失的概率為p，系統允許接收端報文關鍵內容丟失概率為q,那么如何確定以上重發機制中的重發次數k呢？

特殊情況下若報文重發次數為2，分別在每條報文重發機制位注明一個索引號和一個重發編號，發送端發送報文的次序應形如 1.1 ,1.2 ,2.1 ,2.2 ,3.1 ,3.2……其中索引號相同的報文關鍵內容相同，重發編號不同代表同一關鍵內容報文的不同次發送。因此只有出現連續兩次丟失數據報的情況下，報文關鍵內容才可能丟失。出現連續兩次丟失的情況有2種，當x.1 , x.2丟失，此時索引號為x的報文關鍵信息將全部丟失。當x.2,(x+1). 1丟失，丟失報文的索引號不同，此時不會發生報文關鍵信息丟失，因此報文關鍵內容丟失的概率q=p2/2。

  　當報文重發次數為3,依然在每條報文的重發機制位注明索引號和重發號，發送報文的次序應為1.1 ,1.2 ,1.3 ,2.1 ,2.2 ,2.3 ,3.1 ,3.2……。只有出現連續3次丟失數據報的情況報文關鍵信息才可能丟失，列出連續3次丟失報文的情況有3種，當x.1 , x.2 , x.3丟失，此時索引號為x的報文信息全部丟失。當x.2 , x.3 ,(x+1).1或x.3 ,(x+1).1 ,(x+1).2丟失時不影響報文的準確傳遞。因此此時報文關鍵內容丟失的概率q=p3/3。

推廣至一般情況易得當報文重發次數為k時，報文關鍵內容丟失的概率q=pk/k，移項有kq=pk。于是我們得到求重發次數k的方法

1) 根據網絡狀況獲得報文丟失概率p；

2) 根據客戶需求取得報文關鍵內容的允許丟失率范圍q；

3) 分別作出y=px和y=qx的圖像；

4) 求得兩圖像的交點的x坐標，并將x坐標值取整加一即為所求重發次數k。

本文實驗中，需求方允許報文關鍵信息丟失概率q=0.0001,我們分別對上位機發送端和下位機接收端收發的報文進行了統計，在某一固定時間段內，上位機共發送報文19665條，接收端接收報文18636條，傳輸過程中丟失的報文19665-18636=1029條，當前網絡環境下的報文丟失率為，即p=0.0523。據此數值分別作出y=0.0001x的曲線和y=0.0523 x的曲線，取得兩曲線交點x坐標為x≈2.78，最后將x=2.78取整加1得到k=3，即上位機對同一數據報的重發次數應該定為3次就可保證系統丟失報文的概率低于0.0001。

5 結論與展望

本文從硬件平臺搭建、linux移植以及udp協議編程幾個方面介紹了arm-linux環境下udp協議通信的具體實現，并分析了一種在實際嵌入式項目中常用的上位機數據報重發機制，最后對這種機制中的重發次數的確定方法給出了求解過程，為后續的具體項目實施提供了實踐依據，也希望為其他應用這種重發機制的嵌入式產品開發者們提供了借鑒。

參考文獻：

[1] 李偉.基于arm9的嵌入式linux手持平臺的設計與實現[d].武漢:武漢理工大學碩士學位論文,2009.

范艷開.基于arm的嵌入式linux操作系統移植[d].西安:西北工業大學,2005.

udp協議范文3

【關鍵詞】 衛星應急通信 維護臺 UDP 可靠通信

一、引言

當突發災害發生的時候，常規的地面通信設備或者系統就會遭到嚴重破壞，衛星應急通信系統將能夠確保關鍵信息的傳輸，使上級能夠根據災情進行有效的指揮，從而拯救更多的生命和財產。衛星應急通信的特點是：具有開通時間短、傳輸距離遠、通信容量較大、網絡部署快、組網方式靈活、可以實現數據的雙向傳輸。衛星應急通信系統如圖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?；钕ⅲ糜阪溌返耐〝鄼z測。?；钚畔⒓皵祿⑹瞻l所用端口為：初始化收發序號均為0，狀態均為DOWN，KEEP_ALIVE的周期為3秒，連續3次KEEP_ALIVE發送后，對方無響應認為鏈路DOWN，并且清除隊列，暫停保活定時、等待新的連接，否則發送新的?；顖笪?。

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協議范文4

關鍵詞：MODBUS/UDP協議；實時性；智能控制；數據傳輸

前言

目前，從工業控制的發展趨勢來看、不難發現以太網將會成為通信領域的主流技術，因其在性能和速度方面都有很大的提高，并且在全球范圍內得到了廣泛的應用。雖然它在工控領域得到了迅猛發展，但現有的以太網技術不能完全滿足對數據確定實時的要求，因此，現場總線基金會和一些從事工控方面的公司都采用了多種方法來改進以太網。人們設想直接修改以太網MAC協議方式，但它卻有著自身的不足一一成本太高。另外，還有的研究人員想通過在數據鏈路層增加實時調度層的方式來提高實時性，再有就是采用以太網與TCP/IP相結合的方法，在本文中主要是采用MODBUS/UDp協議來減少網絡時延的方式來達到對數據實時性的要求。

在智能建筑行業中有很多監控方面的智能儀表，來達到對監控對象的實時監控，由于各種智能儀表的型號、通訊接口、通訊協議不同，無法直接進行網聯。隨著信息化網絡化的需求不斷提升，對監控對象數據的實時采集、精確控制和遠程協調提出了更高的要求。本文介紹了(1)在已有的以太網絡技術基礎上實現現場智能儀表的聯網，(2)利用MODBUS/UDP協議來進行對數據的準確可靠的實時傳輸和控制。如何將檢測到的數據上傳到檢測中心，檢測中心又如何將各種控制命令下發到各現場機，有多種方法，如利用GSM或CDMA等無線傳輸方法、DDNTM等數據專線、IP網絡。在這些傳輸方案中，利用IP網絡無疑是理想的方法。

監測系統的組成

該系統基于互聯網技術，并采用B/S軟件構架，即Browser/Server(瀏覽器/服務器)結構，是隨著Luternet技術的興起，對c/s結構的一種變化后改進的結構，在這種結構下，用戶界面完全通過WWW瀏覽器實現，一部分事物在前端實現，但是主要事物邏輯在服務器端實現，隨著Windows 98/Windows 2000將瀏覽器技術植入操作系統內部，這種結構更成為當今應用軟件的首選體系結構。

設計出了一個基于以太網構架的建筑監測系統。如圖1所示。

系統由監控中心(服務器PC機)、TCP/IP傳輸網絡、傳輸設備(機頂盒、多串口設備等)、現場機等組成。監控中心有權通過傳輸網絡與各監控設備連接，采集其檢測數據，或者發出控制指令。同時還可以分析、處理、查詢、存儲相關數據、是檢測系統的核心。

現場機安裝在需要監測的控制點，用于監控、監測電能使用情況，并完成與上位機的數據通訊。在圖1中所應用的就是一種集RS485總線接口、MODBUS通訊接口和存儲于一體的智能儀表。根據RS485標準，數據傳輸率在100kbit/s時通信距離可達1200米，選擇帶有RS485接口的另一原因就是在目前市場中這種智能儀表的成本較低，而且它完全能滿足在工控中對監測和數據傳輸的要求。

機頂盒通過嵌入式網絡監控編碼器實現本地數據壓縮并將監測數據通過網絡傳送到監控中心，提供各種接口與PC機相連，能將RS485口轉換成10/100M口，實現數據的網絡化并上傳監控，采用lO/100M接口實現TCP/IP網絡管理和監控，更有利于監控的IP網絡化管理。

MODBUS/UDP協議

在目前的建筑控制系統中使用最廣泛的是MODBUS/TCP通訊協議，但在實際的應用中我們會發現MODBUS/TCP協議確實達到了數據傳輸的可靠性要求，在建立網絡連接時首先要進行三次握手，對數據進行封裝、傳輸，當監控中心收到信息時再返回一個確認信息，在這一系列過程中，MODBUS/TCP協議花費了大量的時間，因此也無法達到人們對數據的實時性傳輸的要求。針對建筑環境通信的特點和以上問題，本文中采用MoDBUS/UDP協議。MODBUS/UDP協議，是將MODBUS協議與以太網UDP協議結合形成的，UDP協議是面向非連接的，其實時性高，通信效果好。UDP的實時性主要是在一個完整的周期通訊中，報文總的傳輸延遲減小，網絡的利用率提高，節點的響應速度也就隨之得到了提升，因此能完成數據的實時傳輸。對于協議的可靠性、雖然不能從協議本身進行改進，但通過編寫好上層軟件，依然可以彌補MODBUS/UDP協議的不足。UDP具有TCP所望塵莫及的速度優勢，盡管TCP協議中有各種安全保障功能，但是在實際執行的過程中占用了大量的系統資源，從而對傳輸速度產生嚴重影響。

將一組數據從傳感器傳輸到控制器或從控制器傳輸到執行器，導致數據延時的因素主要有數據的封裝等待時延Twsit，從傳感器到控制器的網絡時延Tsc，控制器到執行器的網絡時延Tca。也就是總時延T＝Twsit＋Tsc＋Tca，假若在網絡不擁堵的情況下，對比UDP和TCP的數據傳輸時延，我們會發現TCP所用的時間要比UDP的長，主要是因為在封裝數據時TCP協議要在數據中添加以太網幀頭和以太網幀尾，這就延長了Twsit的時間。在MODBUS協議中具有讀寫線圈、讀寫寄存器、讀寫異常等功能，因此我們就可以省去診斷、讀取記錄、編程等設備控制碼，節省了時間，使得傳輸過程的總時延減小，提高了控制中對實時性的要求。

MODBUS協議定義了一個與基礎通信層無關的PDU(協議數據單元)。特定總線或網絡上的MODBUS協議映射能夠在ADU(應用數據單元)上引入附加域。

標準的MODBUS報文協議幀的地址域為1字節大小，為了能在網絡控制總線上采用令牌總線的方式來使得每個站點都有均等的機會來發送數據，采用隱性令牌的方式來避免介質訪問引發的沖突，將1字節的地址域擴大為2字節，地址域分為1字節的目的地址和1字節的源地址，1字節的功能碼變為2字節。改進后的幀格式如圖3所示。

目的地址是該幀的接受地址：源地址是發送幀的地址：狀態位則用來表示發送的幀是否被接收。網絡管理者給每個節點分配一個眭一的地址。每個站點監視收到的每個報文幀的源地址，并為接收到的源地址設置一個 隱h生令牌寄存器，讓隱性令牌寄存器的值為收到的源地址加1、若隱性令牌寄存器的值與哪個站點的介質訪問控制MAC地址相同時、該站點則發送數據，若沒有數據可發送則發送一個空幀，在網絡中沒有真正的令牌幀在網絡中傳輸，而是將令牌隱含在普通的數據中。UDP上的MODBUS的請求/響應格式如圖4所示。

另外，報文中要加上專業的MAPH頭(Modbus Application ProtocolHeader)，以達到識別MODBUS應用數據單元ADU的目的。報文頭為7個字節長度、包括：事務處理標識符(Transaction Identifier)、協議標識符(Protocol Identifier)、長度(Length Field)、單元標識符(UnitIdentifier)。

事務處理標識符：用于事務處理配對。在響應中、MODBUS服務器復制請求的事務處理標識符。

協議標識符：用于系統內的多路復用。通過值0識別MODBUS協議。

長度：長度域是下一個域的字節數，包括單元標識符和數據域。

單元標識符：專門用于以太網TCP/IP網絡和MODBUS串行鏈路之間的網關對MODBUS或MODBUS＋串行鏈路從站的通信。

實驗結果分析

在LABVEIW軟件平臺上進行了模擬實驗，對MODBUS/UDP傳輸數據流進行檢測，MODBUS/UDP協議進行數據傳輸時的數據流量在242Kbps到250Kbps之間。其原理圖與結果如圖5和圖6所示。

當發送端的連接建立起來后，將正弦信號輸入數據類型轉換器，將轉換后的數據發送到UDP端口，UDPwrite根據所設置的傳輸端口對數據進行傳輸。在接收端UDP read根據主機端口號讀取數據、在讀取數據過程中為能監控到數據的傳輸流量，在接收處的傳輸末端使用框圖來顯示對數據的監控情況。

為了進行比較，對同一組隨機數據的傳輸也使用了MODBUS/TCP協議。流量監控數據在236Kbps在245Kbps之間，我們不難發現MODBUS/TCP的傳輸速率明顯要比MODBUS/UDP低。導致這種現象的原因在第三部分已經給出了分析，在LABVEIW上進行模擬仿真不存在現實中Tsc和Tca時延的問題，因此進一步證明了MODBUS/UDP在封裝部分時間短，占用網絡資源少，能快速對采集到的數據進行傳輸。

結果表明，上位機使用MODBUS/UDP協議對測控終端進行查詢并讀取終端的數據，MODBUS/UDP具有更好的實時性，因此對于有大量數據進行傳輸時會減少堵塞問題的出現，因此使用MODBUS/UDP能實現數據高效和實時的傳輸。

udp協議范文5

【關鍵詞】HTTP2Sock，Sock2HTTP，隧道

1 引言

基于SIP協議的即時通信系統在企事業單位使用較多，而隨著單位保密意識的提高，對數據安全和網絡安全的重視，人們對防火墻訪問規則等安全策略的要求越來越嚴格，同時也限制了其基于計算機的各種應用，阻礙了其業務的發展。本文采用HTTP Tunnel實現對防火墻的穿越，將TCP、UDP等非HTTP數據類型進行HTTP偽裝和加密，在不改變單位的防火墻等安全策略的前提下，以隱蔽通信的方式完成應用程序的數據傳輸。

本文重點探討了HTTP Tunnel技術在以SIP協議為基礎的即時通信系統中的應用，并提出相應解決方案和參考應用框架。旨在提升HTTP Tunnel技術的應用范圍，加強應用業務的數據安全與網絡安全。

2 應用系統框架

HTTP Tunnel被稱之為HTTP暗道，原理是將數據偽裝成 HTTP的數據形式來穿過防火墻。

基于SIP協議的即時通信系統是以SIP為信令交互協議的即時通信系統，其應用包括HTTP訪問、即時消息、語音通信、視頻通信等。該系統通過HTTP Tunnel可以不用改變防火前的安全策略，即可實現自由通信。其框架基本包括四個主要方面：

1） 基于SIP協議的即時通信系統，該系統實現基于TCP、UDP、HTTP等協議的即時通信功能；

2） Sock2HTTP服務器，該服務器實現非HTTP協議數據包的HTTP格式轉換，通信端口映射，擁塞控制等功能；

3） HTTP Tunnel系統，該系統實現基于HTTP協議的雙向的虛擬數據連接，從而穿越防火墻；

4） HTTP2Sock服務器，該服務器實現需要轉換為其他格式的HTTP數據，通信端口的映射，擁塞控制等。

其拓撲圖如圖1：

圖1.基于SIP協議的即時通信系統的HTTP Tunnel應用

3應用系統設計

3.1基于SIP協議的即時通信系統

基于SIP協議的即時通信系統主要有兩部分組成。OpenSIPS服務器和oSIP客戶端。

3.1.1 OpenSIPS

OpenSIPS是成熟的開源SIP服務器，結構非常靈活，其核心路由功能完全通過腳本來實現，可靈活定制各種路由策略，可靈活應用于語音、視頻通信、IM以及Presence等多種應用。

其主要功能如下：

 SIP注冊服務器/服務器/重定向服務器

 SIP presence agent

 SIP IM Server

3.1.2 oSIP

oSIP是使用標準c編寫的SIP協議棧。

主要包括兩部分的內容：狀態機模塊、解析器模塊。

 狀態機模塊的功能：完成對某個事務（注冊過程，呼叫過程等等）狀態記錄，并在特定狀態下觸發相應的事件或回調函數。

 解析器模塊的功能：該模塊主要完成對SIP消息結構剖析、SDP消息的結構剖析以及URI結構的剖析；

圖2.oSIP結構

oSIP為SIP協議的客戶端，OpenSIPS為SIP協議的服務器，二者共同搭建基于SIP協議的即時通信系統。

3.2 Sock2HTTP服務器和HTTP2Sock服務器

當位于內網的SIP終端訪問外網，則終端建立連接的端口不一定被防火墻開放，尤其是UDP端口，若使TCP與UDP等消息穿越防火墻則需要相應的協議轉換服務器，即Sock2HTTP和HTTP2Sock。

圖3.Sock2HTTP與HTTP2Sock

3.2.1功能描述

主要負責分配對應的UDP端口；接收HTTP消息、解碼、以UDP的形式發送至目的地址；接收UDP消息、編碼、接收終端分配UDP端口的HTTP消息，返回生成的UDP端口；UDP端口與終端的對應管理機制。

3.2.2設計說明

a．建立TCP套接字，與某端口綁定（可配置），監聽該端口；

b．接收到請求后，fork子進程處理該請求,請求包括要求分配端口的請求和其他請求兩類；

c．處理要求分配端口的請求，將分配的端口返回給終端，保持該TCP鏈接不斷開，直至通話結束或者終端注銷。

4結論

基于SIP協議的即時通信系統使用HTTP Tunnel技術，在企事業單位網內外實現自由通信。該應用不僅提升HTTP Tunnel技術的應用范圍，更加強應用業務的數據安全與網絡安全。系統采用分布式設計，為系統升級和集成提供很好的構架基礎，是企事業單位業務和數據穿越防火墻的一種安全和高效的應用。

參考文獻

[1] RFC 2543 3261SIP: Session Initiation Protocol.

[2] RFC 2616Hypertext Transfer Protocol -- HTTP/1.1.

udp協議范文6

關鍵詞：NAT；UDP Hole Punching；完全P2P；FSN

0　引言

網絡地址轉換協議(NAT：Network Address Translation)，通過將局域網上的主機地址映射為Internet上的合法IP地址，從而實現網絡地址復用。NAT對解決當前IP地址短缺問題、構建防火墻、保證網絡安全等都發揮了重要作用。但是隨著基于Internet的P2P網絡技術的廣泛應用，更多的內網主機需要參與到P2P中來。NAT協議下的主機IP地址(私網IP地址)在Internet上是不可見的，Internet上的主機不能主動訪問這些NAT協議下的主機，而位于不同NAT協議下的主機間更是無法相互識別而不能直接交換信息。但是P2P網絡要求任何主機之間都能夠直接對等交換信息，因此P2P網絡應用必須解決穿越NAT實現雙向對等通信的問題。

本文將重點圍繞著Cone NAT穿越的完全P2P通信方法展開研究。

1　網絡地址轉換(NAT)的類型劃分

按照端口號轉換與否，NAT可以分為以下兩種：

(1)Basic NAT：將私網主機的私有IP地址轉換成公網IP地址，但并不轉換TCP/UDP端口信息。

(2)Network Address Port Translation(NAPT)：NAPT將單獨的公網IP地址和內部多臺主機進行綁定，當不同的內部主機和外部通信時，NAT不僅將內部主機的私有IP轉換為公網IP，而且連端口號一起轉換。

按照端口號的分配情況，NAPT又可以分為以下兩種：

(1)Symmetric NAT：當同一個內部主機向不同的外網主機發起多個會話時，Symmetric NAT為這些會話分配不同的端口，Symmetric NAT能夠區別多個不同的會話并進行地址轉換。

(2)Cone NAT：與Symmetric NAT不同，當同一個內部主機向不同的外網主機發起多個會話時，Cone NAT為這些會話分配同一個端口，并通過判斷數據包的來源(即反饋數據包中的IP地址和端口)來維持會話。所分配的同一個端口在所有會話結束后才收回。

由于當前的NAT幾乎都是Cone NAT，所以本文只是基于Cone NAT進行了研究，后面出現的NAT要是不特別說明，指的是Cone NAT。

2　P2P節點穿越Cone NAT方法

UDP是簡單的傳輸協議，幾乎不提供可靠性措施，是無連接的協議，但是效率非常高。不像TCP協議，傳輸數據之前要建立一種虛擬的連接關系，它只要知道對方的IP地址和UDP端口，就可以進行數據傳輸。在P2P網絡中，采用UDP方式進行數據傳輸，所以能夠獲得主機的Internet合法IP地址就可以進行數據交換。

P2P的兩個節點分布有以下幾種情況：

(1)兩個節點都有自己的公網地址。

(2)兩個節點都使用同一個Cone NAT。

(3)一個節點有公網地址，另外一個節點使用一個ConeNAT協議。

(4)兩個節點使用不同的Cone NAT。

下面就對兩個P2P節點在不同內網下，穿越NAT的User Datagram Protocol(UDP)Hole Punching方法進行介紹。

如圖1所示，假設兩臺主機A和B處于不同的Cone NAT協議下。它們穿越NAT進行直接通信的過程如下：