前言：中文期刊網(wǎng)精心挑選了udp協(xié)議范文供你參考和學(xué)習(xí)，希望我們的參考范文能激發(fā)你的文章創(chuàng)作靈感，歡迎閱讀。
udp協(xié)議范文1
關(guān)鍵詞:通信網(wǎng)絡(luò);基于樣本塊的方法;udp協(xié)議;Mean-Shift方法
中圖分類號:TP311文獻(xiàn)標(biāo)識碼:A文章編號:1009-3044(2010)21-5714-02
通信網(wǎng)絡(luò)為計算機(jī)信息的獲取、傳輸、處理、利用和共享提供一個安全可靠的環(huán)境和傳輸通道,但現(xiàn)實(shí)中通信網(wǎng)絡(luò)并非是絕對安全的,傳輸數(shù)據(jù)過程中數(shù)據(jù)包的丟失、泄密和篡改時有發(fā)生,且日趨嚴(yán)重。
目前在通信網(wǎng)絡(luò)中比較常用的兩個通信協(xié)議是TCP協(xié)議和UDP協(xié)議。TCP是一種面向連接的協(xié)議,采用“三次握手”方式來確保數(shù)據(jù)的準(zhǔn)確接收,其工作機(jī)制是首先是建立連接;其次發(fā)送端發(fā)送數(shù)據(jù),接收端接收數(shù)據(jù);再次接收端向發(fā)送端發(fā)送反饋信息,如果發(fā)送數(shù)據(jù)被成功接收,則斷開連接,否則必須重傳發(fā)送失敗的數(shù)據(jù)。而UDP協(xié)議是一種無連接的協(xié)議,不提供可靠的信息發(fā)送機(jī)制,因此在數(shù)據(jù)傳輸過程當(dāng)中更容易出現(xiàn)數(shù)據(jù)包的丟失現(xiàn)象。
TCP協(xié)議雖說提供安全的數(shù)據(jù)傳輸,但是傳輸效率不高,因此不適合于實(shí)時性較高的應(yīng)用。UDP協(xié)議雖說不提供安全的數(shù)據(jù)傳輸,但是其傳輸效率很高,能實(shí)現(xiàn)實(shí)時傳輸,但是容易出現(xiàn)丟失數(shù)據(jù)包的問題。在實(shí)際當(dāng)中很多實(shí)時性很高的珍貴數(shù)據(jù)是不容有失的,那么如何解決這一問題呢?
在2003年Shantanu D.Rane等提出無線電傳輸中丟失數(shù)據(jù)復(fù)原的問題,他們結(jié)合現(xiàn)有的圖像修復(fù)技術(shù)和紋理合成技術(shù)對傳輸過程中丟失的數(shù)據(jù)進(jìn)行填充。在傳輸過程中,圖像被劃分為 的塊,計算其離散余弦變換,然后量化并進(jìn)行哈弗曼編碼,最后傳輸圖像數(shù)據(jù)[1]。該文獻(xiàn)中對丟失數(shù)據(jù)填充過程如下:對丟失的塊分類,根據(jù)周圍的塊判斷丟失塊是紋理塊還是結(jié)構(gòu)塊,如果是紋理塊使用紋理合成算法,否則使用結(jié)構(gòu)修復(fù)算法。分析發(fā)現(xiàn)該方法對于塊的分類不夠準(zhǔn)確,而且丟失數(shù)據(jù)的填充比較耗時。
本文針對上述缺陷直接使用基于樣本塊的方法[3]填充UDP協(xié)議丟包數(shù)據(jù)。在目前所有的圖像修復(fù)方法中,基于樣本塊的修復(fù)方法是非常有效用的一種,它不僅能夠填充圖像紋理部分,而且能夠修復(fù)圖像簡單的結(jié)構(gòu),對結(jié)構(gòu)的修復(fù)主要是受修復(fù)的優(yōu)先權(quán)和樣本塊的大小控制,適合的修復(fù)順序和樣本塊大小是有利于圖像結(jié)構(gòu)的保持。因此本文直接使用基于樣本塊的方法對丟失的圖像數(shù)據(jù)進(jìn)行填充,這樣不僅能夠提高填充的效率,而且能夠減輕數(shù)據(jù)包的丟失造成嚴(yán)重?fù)p失。
1 基于樣本塊的丟失圖像數(shù)據(jù)填充
UDP協(xié)議的數(shù)據(jù)傳輸過程與無線電數(shù)據(jù)的傳輸是相似的,其優(yōu)點(diǎn)是傳輸過程中的部分?jǐn)?shù)據(jù)丟失不會引起整個圖像數(shù)據(jù)的混亂,這就為數(shù)據(jù)的恢復(fù)提供了一定的可能,否則數(shù)據(jù)的恢復(fù)是非常困難的。在很多文獻(xiàn)中提到UDP協(xié)議的丟包率與具體網(wǎng)絡(luò)環(huán)境有關(guān),沒有一個準(zhǔn)確的數(shù)值,但是一般來說其平均丟包率總會小于無線電數(shù)據(jù)的丟包率3.6%[2]。
基于樣本塊的方法一種非常有效的丟失圖像數(shù)據(jù)的填充方法,它不僅能填充大塊的紋理破損,而且能夠修復(fù)較小的結(jié)構(gòu)破損。UDP協(xié)議的丟包率一般來說很小,這也就為圖像的結(jié)構(gòu)部分的復(fù)原提供了重要的保障。基于樣本塊的圖像修復(fù)過程如下:
1) 確定丟失數(shù)據(jù)包的位置,因為圖像數(shù)據(jù)是經(jīng)過編碼后傳輸?shù)?因此即使丟包也不會使得整個圖像數(shù)據(jù)混亂,自然其丟失數(shù)據(jù)的位置容易確定;
2) 尋找破損區(qū)域的邊緣;
3) 按照優(yōu)先權(quán)計算方法確定當(dāng)前優(yōu)先權(quán)最高的像素點(diǎn),優(yōu)先權(quán)P(p)一般為信任度因子C(p)與數(shù)據(jù)因子D(p)的積。信任度因子和數(shù)據(jù)因子的計算如式(1)和式(2):
(1)
(2)
信任度因子確保了當(dāng)前待修復(fù)塊上有更多的已知像素點(diǎn)來確保找到的最佳匹配塊的準(zhǔn)確性,而數(shù)據(jù)因子表示破損區(qū)域邊界在優(yōu)先權(quán)最高像素點(diǎn)處的法線與該點(diǎn)處等照線的夾角,夾角越大則結(jié)構(gòu)越強(qiáng),否則結(jié)構(gòu)越弱,結(jié)構(gòu)越強(qiáng)的自然越先修復(fù),這樣有利于圖像邊緣的保持;
4) 根據(jù)相似度的度量機(jī)制,尋找最佳匹配塊;
5) 將最佳匹配塊中的數(shù)據(jù)拷貝到當(dāng)前待修復(fù)塊中,注意只拷貝當(dāng)前塊中破損像素點(diǎn)對應(yīng)的數(shù)據(jù);
6) 更新破損區(qū)域;
7) 判斷破損像素點(diǎn)的個數(shù)是否為0,如果為0,則轉(zhuǎn)8),否則返回到2);
8) 修復(fù)結(jié)束。
基于樣本塊的修復(fù)方法雖說有很好的修復(fù)效果,但是也必須注意其修復(fù)過程中存在的問題。首先誤差的累積問題,這必然導(dǎo)致錯誤的填充結(jié)果。其次是最佳匹配塊的選擇問題,如何在多個候選最佳匹配塊中選出真正最佳的匹配塊。
文獻(xiàn)[4]提出一種新的方法來解決這誤差累積的問題,首先使用Mean-Shift方法[5]對圖像進(jìn)行了粗劃分,對最佳匹配塊的選擇區(qū)域作了限制,具體的最佳匹配塊的選擇原則如下:
1) 如果待修復(fù)塊屬于粗劃分Ti,則最佳匹配塊僅在Ti中選擇;
2) 如果待修復(fù)塊處于多個劃分Ti∪Ti+1∪...∪Ti+k的邊緣,則最佳匹配塊在Ti∪Ti+1∪...∪Ti+k中選擇。
上述方法相當(dāng)于給匹配塊的選擇加了一些約束,使選擇范圍縮小。這樣不僅縮短了尋找匹配塊的時間,也避免了誤差的累積。
另外一個問題就是最佳匹配塊唯一的問題。假設(shè)目前找到的匹配塊為ψp1, ψp2,…ψpk,那么如何在這之中選擇一個真正的最佳匹配塊。文獻(xiàn)[6]提到了一種選取最佳匹配塊的方法,認(rèn)為與當(dāng)前待修復(fù)塊的空間距離越近,其相關(guān)程度越高。因此,通過計算待修復(fù)塊的核與匹配塊的核之間的空間距離來最終選定哪個塊是真正的最佳匹配塊。丟失數(shù)據(jù)的填充流程圖如圖1所示。
2 實(shí)驗結(jié)果
本文用VC++實(shí)現(xiàn)了該算法,通過大量的實(shí)驗說明了本文算法的有效性。由于傳輸圖像很容易獲得,因此本文采用峰值信噪比的方法對恢復(fù)結(jié)果進(jìn)行客觀評價。峰值信噪比PSNR的計算如下式:
(3)
PSNR值越大,恢復(fù)的效果越好,越接近原圖;PSNR值越小,恢復(fù)效果越差,與原圖差異越大。恢復(fù)結(jié)果如圖2、圖3、圖4所示。
4 結(jié)論
本文分析了通信網(wǎng)絡(luò)中UDP協(xié)議的傳輸機(jī)制,發(fā)現(xiàn)UDP協(xié)議在傳輸數(shù)據(jù)時容易發(fā)生數(shù)據(jù)丟包問題,由此使用基于樣本塊的方法解決恢復(fù)丟失數(shù)據(jù)包的問題。盡管文獻(xiàn)[1]的作者提出了無線傳輸中圖像數(shù)據(jù)的恢復(fù)方法,但是該方法比較復(fù)雜,而且存在諸多的不穩(wěn)定性,諸如塊的分類等。本文結(jié)合基于樣本塊修復(fù)的優(yōu)點(diǎn)對丟失數(shù)據(jù)進(jìn)行恢復(fù),并通過實(shí)驗進(jìn)行了驗證,確實(shí)取得了令人滿意的效果。這樣不僅很大程度上提高了UDP協(xié)議圖像數(shù)據(jù)傳輸?shù)陌踩?也提高了UDP協(xié)議的傳輸效率。
參考文獻(xiàn):
[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協(xié)議范文2
關(guān)鍵詞：arm；linux；交叉編譯環(huán)境；udp協(xié)議；重發(fā)機(jī)制；重發(fā)次數(shù)
udp協(xié)議以其高效性和應(yīng)用的簡單，被廣泛運(yùn)用于嵌入式網(wǎng)絡(luò)開發(fā)中。由于udp協(xié)議的應(yīng)用簡單，在嵌入式設(shè)備開發(fā)過程中，網(wǎng)絡(luò)資源的利用率并不高。以下將介紹一個udp具體項目實(shí)驗過程，描述arm-linux環(huán)境的軟硬件環(huán)境構(gòu)建過程，并對udp協(xié)議下一種重發(fā)模式中上位機(jī)的重發(fā)次數(shù)的確定提出一種可行的方法。
1 研究背景
隨著嵌入式技術(shù)的快速發(fā)展，嵌入式設(shè)備已經(jīng)在許多領(lǐng)域取代了傳統(tǒng)的微型機(jī)設(shè)備。本文的選題主要來自于實(shí)習(xí)期間承接的一項改造項目：某院校特長生評分系統(tǒng)的改造。項目改造目的有：1) 保留原上位機(jī)。2) 改用手持式客戶端進(jìn)行顯示及評分操作。3)保留原有網(wǎng)絡(luò)設(shè)備。針對要求，我們使用s3c2440作為硬件平臺，移植linux操作系統(tǒng)，并在arm-linux環(huán)境下研究了udp協(xié)議的通信過程，進(jìn)行了上位機(jī)與嵌入式系統(tǒng)的udp協(xié)議通信實(shí)驗及分析，并給出一種重發(fā)機(jī)制中的發(fā)送次數(shù)求法。
2 硬件平臺介紹
s3c2440處理速度達(dá)到了400mhz，具有較高的性價比。為了提高開發(fā)效率，我們采用公司自行研制開發(fā)的et-s3c2440開發(fā)板。
2.1 et-s3c2440開發(fā)板簡介
et-s3c2440是公司自行開發(fā)的一款arm9架構(gòu)的實(shí)驗開發(fā)板，其結(jié)構(gòu)框圖如圖1。
核心板的主要器件有：32mb×2片sdram，64mb norflash，512mb nandflash。設(shè)計了啟動方式可選，通過開關(guān)選擇從nandflash或norflash啟動。
2.2 實(shí)驗相關(guān)電路說明
底板電路主要功能是輸入輸出以及網(wǎng)絡(luò)通訊功能。按鍵輸入部分采用掃描方式獲得輸入，用一個單向地址鎖存器和一個雙向地址鎖存器與地址總線相連，可以通過掃描地址來獲得按鍵輸入。lcd采用三星的3.5寸tft屏作為顯示輸出設(shè)備。網(wǎng)卡芯片選用的是與原設(shè)備匹配的10m 的cs8900a，關(guān)于cs8900a與s3c2440的硬件連接，有眾多資源可供參考，本文不再贅述。
3 系統(tǒng)軟件平臺的構(gòu)建
硬件平臺搭建完畢后要將操作系統(tǒng)和應(yīng)用程序在硬件平臺上運(yùn)行起來。以下是對嵌入式linux操作系統(tǒng)移植的過程。
3.1 交叉編譯環(huán)境的構(gòu)建
linux 2.6.29.1版本的內(nèi)核可以登錄到下載。本文選擇的是arm-linux-gcc-4.3.2工具鏈()
在宿主機(jī)上進(jìn)入linux系統(tǒng)，切換當(dāng)前目錄到工具鏈所在目錄，新建一個arm目錄保存解壓后的文件(mkdir /user/local/arm)并將arm-linux-gcc-4.3.2解壓到這個目錄中(tar jxvf arm-linux-gcc-4.3.2 –c /user/local/arm)。然后將環(huán)境變量$path修改一下，讓$path中包含有arm-linux-gcc所在的目錄(編輯/etc/profile 添加語句”export path=/user/local/arm/4.3.2/bin:$path”)，然后reboot一下，這樣交叉編譯環(huán)境就構(gòu)建好了。
3.2 bootloader的移植
vivi是一款相當(dāng)成熟和相對簡單的常用bootloader，我們以vivi為移植原型，將s3c2440所有io端口寄存器定義添加到頭文件2440add.inc，刪除部分硬件平臺使用不到的代碼，最后將修改過的vivi制作成鏡像燒錄到flash中。[1]
3.3 linux內(nèi)核移植
獲取linux-2.6.29.1源代碼并解壓后，首先修改內(nèi)核源代碼所在目錄中的makefile，將系統(tǒng)架構(gòu)修改為arm(arch ?=arm ),交叉編譯工具修改為arm-linux-gcc (cross_compile ?=arm-linux-)，修改輸入時鐘(arch/arm/mach-s3c2440/mach-smdk2440.c中的函數(shù)static void __init smdk2440_map_io中，修改s3c24xx_init_clocks(12000000)此處所用晶振為12m)。修改machine名稱(在arch/arm/mach-s3c2440/mach-smdk2440.c文件中的函數(shù)machine_start( ),修改為machine_start(s3c2440, “自定義機(jī)器名”)，修改nandflash分區(qū)信息(arch/arm/plat-s3c24xx/common-smdk.c結(jié)構(gòu)體static struct mtd_partition smdk_default_nand_part[]中保存的是nandflah的分區(qū)信息，將其修改為當(dāng)前使用的分區(qū)信息),然后修改nandflash的匹配時間(3c2410_platform_nand_smdk_nand_info smdk_nand_info ={})。
上述內(nèi)核源代碼修改完成后，還需要對一些設(shè)備的驅(qū)動進(jìn)行修改。本文使用的nec 3.5寸 320×240液晶屏，硬件平臺使用gpg4腳進(jìn)行背光控制，需要修改lcd背光(/arch/arm/mach-s3c2440/mach-smdk2440.c中static void __init smdk2440_machine_init(void)，將函數(shù)中的gpio口配置為gpg4)。關(guān)于cs8900a網(wǎng)卡的驅(qū)動移植，相關(guān)資源很豐富，本文也不再贅述。
本實(shí)驗中nandflash采用的是yaffs2文件系統(tǒng)，所以打yaffs2文件系統(tǒng)補(bǔ)丁，壓縮包為cvs-root.tar.gz。
至此，linux的內(nèi)核源代碼修改工作完成了，下面還需要利用makefile,進(jìn)行內(nèi)核配置。
在linux 2.6.29.1內(nèi)核目錄下首先make s3c2410_defconfig使用2410的配置模板來配置2440；然后make menuconfig,這時我們可以在圖形化界面中，空格鍵可改變各個配置選項的被選中狀態(tài)，根據(jù)需要進(jìn)行配置即可。配置完成后保存好配置，最后進(jìn)行內(nèi)核的編譯(make dep 建立文件間依賴 make clean 清除編譯殘留文件make zimage 生成內(nèi)核壓縮鏡像文件)。
編譯過程完成后會在內(nèi)核目錄arch/arm/boot/下生成zimage內(nèi)核映像文件，將這個鏡像文件燒錄到flash中，調(diào)試檢驗，經(jīng)上述修改后的內(nèi)核工作運(yùn)行正常。
3.4 根文件系統(tǒng)的制作
根文件系統(tǒng)是使用busybox-1.13.3來制作完成。下載busybox并解壓完成后，修改makefile中的架構(gòu)為arm架構(gòu)，編譯工具為arm-linux-gcc( arch ?=arm； cross_compile ?=arm-linux-),然后make menuconfig,通過圖形界面對busybox進(jìn)行配置，然后對busybox進(jìn)行編譯(make config_prefix=/opt/studyarm/rootfs install)，在目標(biāo)目錄下會生成目錄bin、sbin、usr和文件linuxrc的內(nèi)容。
基本目錄結(jié)構(gòu)生成后，應(yīng)該在目標(biāo)目錄下建立一些未生成的必要的系統(tǒng)目錄如dev、etc、lib等，并通過chmod命令改變目錄權(quán)限為可寫。再將一些必要的動態(tài)鏈接庫和靜態(tài)庫拷貝到lib下，然后在dev目錄下創(chuàng)建設(shè)備節(jié)點(diǎn)，最后創(chuàng)建該嵌入式linux系統(tǒng)的初始化配置文件(包括設(shè)備列表文件、口令、網(wǎng)絡(luò)分組組名、hostname主機(jī)名、etc/inittab初始化表單、etc/profile環(huán)境變量配置文件、用于系統(tǒng)初始化的.bash腳本文件等)。由于本實(shí)驗需對網(wǎng)絡(luò)編程，要求自動初始化cs8900a網(wǎng)卡芯片的ip地址、網(wǎng)關(guān)、子網(wǎng)掩碼等，所以在開機(jī)自啟動腳本中加入ifconfig語句，使得開機(jī)時自動配置網(wǎng)卡參數(shù)。
根文件系統(tǒng)構(gòu)建完成后，使用yaffs2文件系統(tǒng)制作工具mkyaffs2image.tgz，通過命令mkyaffs2image rootfs rootfs.img生成根文件系統(tǒng)鏡像，然后將鏡像燒寫入flash中。
4 arm-linux環(huán)境下的udp協(xié)議通信實(shí)驗
經(jīng)過上述硬件設(shè)計和操作系統(tǒng)移植過程，本文所使用到的實(shí)驗環(huán)境已經(jīng)構(gòu)建完畢，經(jīng)反復(fù)調(diào)試修改，嵌入式linux操作系統(tǒng)在平臺下運(yùn)行正常，于是進(jìn)行udp協(xié)議通信實(shí)驗。
4.1 udp協(xié)議套接字編程基礎(chǔ)
udp是一個面向數(shù)據(jù)報和無連接的簡單傳輸層協(xié)議，它不像tcp那樣通過握手過程建立服務(wù)器與客戶端的連接才可以工作。在網(wǎng)絡(luò)通信質(zhì)量較好的情況下，udp體現(xiàn)出高效率，這適合于傳送少量報文的應(yīng)用。 linux系統(tǒng)是通過套接字結(jié)構(gòu)來進(jìn)行網(wǎng)絡(luò)編程的，應(yīng)用程序通過對套接字的幾個函數(shù)調(diào)用，會返回一個用于通信的套接字描述符,而linux應(yīng)用程序在進(jìn)行任何形式的i/o操作時，程序?qū)嶋H上是在讀寫一個文件描述符。因此linux下的套接字編程，可以看成是對普通文件描述符的操作，這些操作與被使用的硬件平臺無關(guān)，這是linux設(shè)備無關(guān)性的優(yōu)點(diǎn)。udp協(xié)議的通信模型如圖3所示。
在上述流程中，客戶端所收到的報文被存儲在緩沖區(qū)中，recvfrom()函數(shù)返回了報文存儲緩沖區(qū)的首地址，我們可以很方便地對這個首地址進(jìn)行數(shù)組操作，從而實(shí)現(xiàn)對報文的解碼。
4.2 上位機(jī)報文結(jié)構(gòu)及重發(fā)機(jī)制分析
根據(jù)項目要求，上位機(jī)軟件依然保留，我們使用協(xié)議嗅探工具對上位機(jī)發(fā)送的報文進(jìn)行了嗅探，得到了上位機(jī)報文的結(jié)構(gòu)如表1所示。
表1 上位機(jī)報文結(jié)構(gòu)
上位機(jī)發(fā)出的每條報文由32個字節(jié)組成，第0位為版本信息。第1……12位為比賽信息和運(yùn)動員教練信息，是報文的關(guān)鍵信息部分，13……22位為服務(wù)器端和客戶端的ip地址及端口號信息，23位是上位機(jī)對客戶端的操作指令代碼，24位是相關(guān)重發(fā)機(jī)制的代碼，30和31兩位是checksum，用來保證數(shù)據(jù)傳輸?shù)恼_。上位機(jī)采用的重發(fā)機(jī)制是一種上位機(jī)按照固定重發(fā)次數(shù)多次發(fā)送同一關(guān)鍵內(nèi)容報文的機(jī)制，其第24位重發(fā)機(jī)制位被分為高4位和低4位兩部分，高四位的內(nèi)容是當(dāng)前發(fā)送的報文的索引號，每次發(fā)送一條新內(nèi)容的報文時索引號自增1，索引號的取值范圍在0x00—0xff范圍內(nèi)循環(huán)自增。低四位是重發(fā)編號，表示同一索引號的報文正在被第幾次重發(fā)，固定的重發(fā)次數(shù)由上位機(jī)初始化時設(shè)定。
4.3 嵌入式客戶端的實(shí)驗程序設(shè)計
針對報文結(jié)構(gòu)，我們對接收端編寫實(shí)驗程序代碼，代碼的主要功能是從上位機(jī)接收報文，將計算出的checksum校驗和與收到的校驗和對比判斷報文是否正確，然后從正確報文中取出主要信息并按照報文中的上位機(jī)指令碼進(jìn)行輸出。其結(jié)構(gòu)流程圖如圖3所示。
實(shí)驗程序經(jīng)編碼、調(diào)試后在交叉編譯環(huán)境中交叉編譯，生成arm-linux環(huán)境下可執(zhí)行文件，在目標(biāo)板上執(zhí)行。經(jīng)測試試驗程序能夠正確接收上位機(jī)發(fā)來的報文，對報文解碼，并能根據(jù)上位機(jī)命令對關(guān)鍵信息做輸出處理。
4.4 對上位機(jī)重發(fā)次數(shù)的研究
進(jìn)行udp協(xié)議通信時，發(fā)送端和接收端的狀態(tài)是相對獨(dú)立的，發(fā)送端不與接收端建立連接，而是不停向接收端發(fā)送，為了確保不丟失報文，上位機(jī)采取了按固定次數(shù)重發(fā)相同內(nèi)容報文的機(jī)制。然而這種機(jī)制雖然可以有效確保報文不丟失，但是大量冗余數(shù)據(jù)報被發(fā)送，網(wǎng)絡(luò)資源利用率不高。重發(fā)次數(shù)越多，冗余數(shù)據(jù)報越多，效率越低。要想有效保證數(shù)據(jù)報準(zhǔn)確發(fā)送的同時又不產(chǎn)生過多冗余數(shù)據(jù)報，那么重復(fù)發(fā)送的次數(shù)的確定就成為問題的關(guān)鍵。以下給出一種確定上位機(jī)重發(fā)次數(shù)的方法。
假設(shè)當(dāng)前網(wǎng)絡(luò)狀況下，每次報文發(fā)送被丟失的概率為p，系統(tǒng)允許接收端報文關(guān)鍵內(nèi)容丟失概率為q,那么如何確定以上重發(fā)機(jī)制中的重發(fā)次數(shù)k呢？
特殊情況下若報文重發(fā)次數(shù)為2，分別在每條報文重發(fā)機(jī)制位注明一個索引號和一個重發(fā)編號，發(fā)送端發(fā)送報文的次序應(yīng)形如 1.1 ,1.2 ,2.1 ,2.2 ,3.1 ,3.2……其中索引號相同的報文關(guān)鍵內(nèi)容相同，重發(fā)編號不同代表同一關(guān)鍵內(nèi)容報文的不同次發(fā)送。因此只有出現(xiàn)連續(xù)兩次丟失數(shù)據(jù)報的情況下，報文關(guān)鍵內(nèi)容才可能丟失。出現(xiàn)連續(xù)兩次丟失的情況有2種，當(dāng)x.1 , x.2丟失，此時索引號為x的報文關(guān)鍵信息將全部丟失。當(dāng)x.2,(x+1). 1丟失，丟失報文的索引號不同，此時不會發(fā)生報文關(guān)鍵信息丟失，因此報文關(guān)鍵內(nèi)容丟失的概率q=p2/2。
當(dāng)報文重發(fā)次數(shù)為3,依然在每條報文的重發(fā)機(jī)制位注明索引號和重發(fā)號，發(fā)送報文的次序應(yīng)為1.1 ,1.2 ,1.3 ,2.1 ,2.2 ,2.3 ,3.1 ,3.2……。只有出現(xiàn)連續(xù)3次丟失數(shù)據(jù)報的情況報文關(guān)鍵信息才可能丟失，列出連續(xù)3次丟失報文的情況有3種，當(dāng)x.1 , x.2 , x.3丟失，此時索引號為x的報文信息全部丟失。當(dāng)x.2 , x.3 ,(x+1).1或x.3 ,(x+1).1 ,(x+1).2丟失時不影響報文的準(zhǔn)確傳遞。因此此時報文關(guān)鍵內(nèi)容丟失的概率q=p3/3。
推廣至一般情況易得當(dāng)報文重發(fā)次數(shù)為k時，報文關(guān)鍵內(nèi)容丟失的概率q=pk/k，移項有kq=pk。于是我們得到求重發(fā)次數(shù)k的方法
1) 根據(jù)網(wǎng)絡(luò)狀況獲得報文丟失概率p；
2) 根據(jù)客戶需求取得報文關(guān)鍵內(nèi)容的允許丟失率范圍q；
3) 分別作出y=px和y=qx的圖像；
4) 求得兩圖像的交點(diǎn)的x坐標(biāo)，并將x坐標(biāo)值取整加一即為所求重發(fā)次數(shù)k。
本文實(shí)驗中，需求方允許報文關(guān)鍵信息丟失概率q=0.0001,我們分別對上位機(jī)發(fā)送端和下位機(jī)接收端收發(fā)的報文進(jìn)行了統(tǒng)計，在某一固定時間段內(nèi)，上位機(jī)共發(fā)送報文19665條，接收端接收報文18636條，傳輸過程中丟失的報文19665-18636=1029條，當(dāng)前網(wǎng)絡(luò)環(huán)境下的報文丟失率為，即p=0.0523。據(jù)此數(shù)值分別作出y=0.0001x的曲線和y=0.0523 x的曲線，取得兩曲線交點(diǎn)x坐標(biāo)為x≈2.78，最后將x=2.78取整加1得到k=3，即上位機(jī)對同一數(shù)據(jù)報的重發(fā)次數(shù)應(yīng)該定為3次就可保證系統(tǒng)丟失報文的概率低于0.0001。
5 結(jié)論與展望
本文從硬件平臺搭建、linux移植以及udp協(xié)議編程幾個方面介紹了arm-linux環(huán)境下udp協(xié)議通信的具體實(shí)現(xiàn)，并分析了一種在實(shí)際嵌入式項目中常用的上位機(jī)數(shù)據(jù)報重發(fā)機(jī)制，最后對這種機(jī)制中的重發(fā)次數(shù)的確定方法給出了求解過程，為后續(xù)的具體項目實(shí)施提供了實(shí)踐依據(jù)，也希望為其他應(yīng)用這種重發(fā)機(jī)制的嵌入式產(chǎn)品開發(fā)者們提供了借鑒。
參考文獻(xiàn)：
[1] 李偉.基于arm9的嵌入式linux手持平臺的設(shè)計與實(shí)現(xiàn)[d].武漢:武漢理工大學(xué)碩士學(xué)位論文,2009.
范艷開.基于arm的嵌入式linux操作系統(tǒng)移植[d].西安:西北工業(yè)大學(xué),2005.
udp協(xié)議范文3
【關(guān)鍵詞】 衛(wèi)星應(yīng)急通信 維護(hù)臺 UDP 可靠通信
一、引言
當(dāng)突發(fā)災(zāi)害發(fā)生的時候，常規(guī)的地面通信設(shè)備或者系統(tǒng)就會遭到嚴(yán)重破壞，衛(wèi)星應(yīng)急通信系統(tǒng)將能夠確保關(guān)鍵信息的傳輸，使上級能夠根據(jù)災(zāi)情進(jìn)行有效的指揮，從而拯救更多的生命和財產(chǎn)。衛(wèi)星應(yīng)急通信的特點(diǎn)是：具有開通時間短、傳輸距離遠(yuǎn)、通信容量較大、網(wǎng)絡(luò)部署快、組網(wǎng)方式靈活、可以實(shí)現(xiàn)數(shù)據(jù)的雙向傳輸。衛(wèi)星應(yīng)急通信系統(tǒng)如圖1所示。
二、基于UDP協(xié)議的衛(wèi)星用戶地面站維護(hù)平臺的設(shè)計
2.1 需求分析
本課題主要針對衛(wèi)星應(yīng)急通信的特點(diǎn)來設(shè)計維護(hù)平臺。當(dāng)?shù)卣饘?dǎo)致常規(guī)地面通信遭到嚴(yán)重破壞時，可以把衛(wèi)星用戶地面站拿過來，作為與衛(wèi)星通信的交換機(jī)，這里就需要一個維護(hù)臺來配置這個衛(wèi)星用戶地面站，讓其快速的進(jìn)入工作狀態(tài)，例如對槽號、話路號的優(yōu)先級、衛(wèi)星呼出權(quán)、CO中繼權(quán)、會議召集權(quán)等參數(shù)的快速配置，從而確保關(guān)鍵信息的及時傳輸。
2.2 接口要求
衛(wèi)星用戶地面站和維護(hù)臺之間通過TCP/IP協(xié)議通信，物理層采用以太網(wǎng)接口。UDP協(xié)議作為傳輸協(xié)議，消息數(shù)據(jù)作為UDP的凈荷。
2.3 基本功能
配置管理功能：完成用戶屬性、會議和衛(wèi)星模塊的配置功能，并具備配置數(shù)據(jù)單獨(dú)文件生成和加載功能；狀態(tài)監(jiān)控：監(jiān)視用戶站的各種工作狀態(tài)，并能完成對用戶站的自檢和自檢結(jié)果處理功能；計費(fèi)功能：完成呼叫記錄的獲取、存儲、檢索和計費(fèi)功能；配置數(shù)據(jù)導(dǎo)出功能：完成從用戶站配置獲取數(shù)據(jù)，并具有配置數(shù)據(jù)單獨(dú)生成配置文件功能；多用戶站管理：維護(hù)臺能夠管理多個用戶站，根據(jù)用戶站ID選擇對應(yīng)的數(shù)據(jù)，但同一時刻只管理一個用戶站。
2.4 通信協(xié)議的格式
消息的組成如表1所示，每條消息以數(shù)據(jù)幀的格式采用FLAG封裝，每一條消息以標(biāo)志字符（FLAG）開始和結(jié)束，A字段為鏈路層凈荷的長度，C字段為一個序號，用于完成消息的可靠傳輸。CRC字段是一個循環(huán)冗余的檢驗碼，以檢測數(shù)據(jù)幀中的錯誤。
三、衛(wèi)星用戶地面站與維護(hù)臺的可靠通信流程
3.1 識別
因為UDP協(xié)議本身是面向無連接的，而本協(xié)議中加入的識別機(jī)制則解決了這一不可靠因素，使連接更快速，更有目的性。本過程完成通信雙方之間的識別，獲得雙方的IP地址。通信采用廣播（廣播地址為255.255.255.255）形式。目的地址均為廣播地址，源地址為發(fā)送方的IP地址。識別過程如下圖2。
3.2 雙線程
維護(hù)平臺后臺啟用兩個線程，分為控制線程與數(shù)據(jù)線程。采用雙線程機(jī)制，即兩個線程采用不同的容錯策略。控制線程在成功進(jìn)行握手后便由數(shù)據(jù)線程來接手?jǐn)?shù)據(jù)的傳輸，中間還需要數(shù)據(jù)端口發(fā)送鏈路保活消息，直至數(shù)據(jù)傳輸結(jié)束，整個過程中的所有檢測消息和數(shù)據(jù)傳輸均采用表1所描述的消息結(jié)構(gòu)。
3.3 鏈路通斷檢測
使用Keep-Alive保活消息，用于鏈路的通斷檢測。保活信息及數(shù)據(jù)消息收發(fā)所用端口為：初始化收發(fā)序號均為0，狀態(tài)均為DOWN，KEEP_ALIVE的周期為3秒，連續(xù)3次KEEP_ALIVE發(fā)送后，對方無響應(yīng)認(rèn)為鏈路DOWN，并且清除隊列，暫停保活定時、等待新的連接，否則發(fā)送新的保活報文。
3.4 停等待機(jī)制
鏈路在UP狀態(tài)下，采用改進(jìn)的停等待機(jī)制。此機(jī)制能保證消息傳送的有序、不重復(fù)、防丟包，使接收方收到準(zhǔn)確無誤的消息。發(fā)送時在沒有收到響應(yīng)消息前，不能進(jìn)行下一條消息發(fā)送，。接收時對于相同序號的消息只處理第一次條，其它的只進(jìn)行確認(rèn)響應(yīng)。通信雙方各自維護(hù)自己的序號C字段，范圍為0～127循環(huán)，接收到消息并確認(rèn)正確后，將序號C字段的第7位置為1，組成響應(yīng)幀發(fā)送給對方，并記錄當(dāng)前接收的對端序號C字段的值，如果再次收到同樣序號C字段的消息只進(jìn)行響應(yīng)而不處理。
四、維護(hù)臺界面的測試
4.1 識別
維護(hù)平臺上加入識別連接界面，進(jìn)行與衛(wèi)星用戶地面站的數(shù)據(jù)通信，能達(dá)到快速識別，以便于對其進(jìn)行快速配置。利用本維護(hù)平臺目前能達(dá)到快速識別和連接到衛(wèi)星用戶地面站。點(diǎn)擊搜索按鈕，客戶端會發(fā)出廣播消息，用戶站收到此消息后會給出響應(yīng)消息，然后客戶端通過對收到的響應(yīng)消息進(jìn)行分析，得到用戶站的IP地址和設(shè)備ID號，并顯示在窗體中。如圖3所示。
4.2 保活
點(diǎn)擊連接按鈕，則線程回歸到主窗體中，主窗體上的信息欄會顯示“連接到用戶站：121.193.211.138”。如果連接中間出現(xiàn)斷開情況，則信息欄會給出“失去與用戶站（121.193.211.138）的聯(lián)系，請重新進(jìn)行設(shè)備識別”的提示，客戶機(jī)應(yīng)進(jìn)行設(shè)備的重新識別和通信連接的建立。
4.3 維護(hù)臺功能模塊的實(shí)現(xiàn)
維護(hù)臺通過以太網(wǎng)連接于用戶站連接，通過發(fā)送廣播包搜索設(shè)備，等1秒后，確認(rèn)是否有連接的用戶站，如果有多個用戶站響應(yīng)，選擇一個作為當(dāng)前設(shè)備，根據(jù)匯報的設(shè)備ID，選擇其對應(yīng)的數(shù)據(jù)庫進(jìn)行工作。
五、結(jié)論
對于衛(wèi)星用戶地面站和維護(hù)臺之間的可靠通信，本文加入了一些機(jī)制，使可靠性得到了保證。對于維護(hù)臺的設(shè)計以簡單、實(shí)用為原則，實(shí)現(xiàn)其要求的基本功能，能夠?qū)崿F(xiàn)快速投入使用、快速配置衛(wèi)星用戶地面站。隨著問題研究的深入，在數(shù)據(jù)傳輸過程中，速率和可靠性之間存在的矛盾將是接下來要解決的問題。
參 考 文 獻(xiàn)
udp協(xié)議范文4
關(guān)鍵詞：MODBUS/UDP協(xié)議；實(shí)時性；智能控制；數(shù)據(jù)傳輸
前言
目前，從工業(yè)控制的發(fā)展趨勢來看、不難發(fā)現(xiàn)以太網(wǎng)將會成為通信領(lǐng)域的主流技術(shù)，因其在性能和速度方面都有很大的提高，并且在全球范圍內(nèi)得到了廣泛的應(yīng)用。雖然它在工控領(lǐng)域得到了迅猛發(fā)展，但現(xiàn)有的以太網(wǎng)技術(shù)不能完全滿足對數(shù)據(jù)確定實(shí)時的要求，因此，現(xiàn)場總線基金會和一些從事工控方面的公司都采用了多種方法來改進(jìn)以太網(wǎng)。人們設(shè)想直接修改以太網(wǎng)MAC協(xié)議方式，但它卻有著自身的不足一一成本太高。另外，還有的研究人員想通過在數(shù)據(jù)鏈路層增加實(shí)時調(diào)度層的方式來提高實(shí)時性，再有就是采用以太網(wǎng)與TCP/IP相結(jié)合的方法，在本文中主要是采用MODBUS/UDp協(xié)議來減少網(wǎng)絡(luò)時延的方式來達(dá)到對數(shù)據(jù)實(shí)時性的要求。
在智能建筑行業(yè)中有很多監(jiān)控方面的智能儀表，來達(dá)到對監(jiān)控對象的實(shí)時監(jiān)控，由于各種智能儀表的型號、通訊接口、通訊協(xié)議不同，無法直接進(jìn)行網(wǎng)聯(lián)。隨著信息化網(wǎng)絡(luò)化的需求不斷提升，對監(jiān)控對象數(shù)據(jù)的實(shí)時采集、精確控制和遠(yuǎn)程協(xié)調(diào)提出了更高的要求。本文介紹了(1)在已有的以太網(wǎng)絡(luò)技術(shù)基礎(chǔ)上實(shí)現(xiàn)現(xiàn)場智能儀表的聯(lián)網(wǎng)，(2)利用MODBUS/UDP協(xié)議來進(jìn)行對數(shù)據(jù)的準(zhǔn)確可靠的實(shí)時傳輸和控制。如何將檢測到的數(shù)據(jù)上傳到檢測中心，檢測中心又如何將各種控制命令下發(fā)到各現(xiàn)場機(jī)，有多種方法，如利用GSM或CDMA等無線傳輸方法、DDNTM等數(shù)據(jù)專線、IP網(wǎng)絡(luò)。在這些傳輸方案中，利用IP網(wǎng)絡(luò)無疑是理想的方法。
監(jiān)測系統(tǒng)的組成
該系統(tǒng)基于互聯(lián)網(wǎng)技術(shù)，并采用B/S軟件構(gòu)架，即Browser/Server(瀏覽器/服務(wù)器)結(jié)構(gòu)，是隨著Luternet技術(shù)的興起，對c/s結(jié)構(gòu)的一種變化后改進(jìn)的結(jié)構(gòu)，在這種結(jié)構(gòu)下，用戶界面完全通過WWW瀏覽器實(shí)現(xiàn)，一部分事物在前端實(shí)現(xiàn)，但是主要事物邏輯在服務(wù)器端實(shí)現(xiàn)，隨著Windows 98/Windows 2000將瀏覽器技術(shù)植入操作系統(tǒng)內(nèi)部，這種結(jié)構(gòu)更成為當(dāng)今應(yīng)用軟件的首選體系結(jié)構(gòu)。
設(shè)計出了一個基于以太網(wǎng)構(gòu)架的建筑監(jiān)測系統(tǒng)。如圖1所示。
系統(tǒng)由監(jiān)控中心(服務(wù)器PC機(jī))、TCP/IP傳輸網(wǎng)絡(luò)、傳輸設(shè)備(機(jī)頂盒、多串口設(shè)備等)、現(xiàn)場機(jī)等組成。監(jiān)控中心有權(quán)通過傳輸網(wǎng)絡(luò)與各監(jiān)控設(shè)備連接，采集其檢測數(shù)據(jù)，或者發(fā)出控制指令。同時還可以分析、處理、查詢、存儲相關(guān)數(shù)據(jù)、是檢測系統(tǒng)的核心。
現(xiàn)場機(jī)安裝在需要監(jiān)測的控制點(diǎn)，用于監(jiān)控、監(jiān)測電能使用情況，并完成與上位機(jī)的數(shù)據(jù)通訊。在圖1中所應(yīng)用的就是一種集RS485總線接口、MODBUS通訊接口和存儲于一體的智能儀表。根據(jù)RS485標(biāo)準(zhǔn)，數(shù)據(jù)傳輸率在100kbit/s時通信距離可達(dá)1200米，選擇帶有RS485接口的另一原因就是在目前市場中這種智能儀表的成本較低，而且它完全能滿足在工控中對監(jiān)測和數(shù)據(jù)傳輸?shù)囊蟆?/p>
機(jī)頂盒通過嵌入式網(wǎng)絡(luò)監(jiān)控編碼器實(shí)現(xiàn)本地數(shù)據(jù)壓縮并將監(jiān)測數(shù)據(jù)通過網(wǎng)絡(luò)傳送到監(jiān)控中心，提供各種接口與PC機(jī)相連，能將RS485口轉(zhuǎn)換成10/100M口，實(shí)現(xiàn)數(shù)據(jù)的網(wǎng)絡(luò)化并上傳監(jiān)控，采用lO/100M接口實(shí)現(xiàn)TCP/IP網(wǎng)絡(luò)管理和監(jiān)控，更有利于監(jiān)控的IP網(wǎng)絡(luò)化管理。
MODBUS/UDP協(xié)議
在目前的建筑控制系統(tǒng)中使用最廣泛的是MODBUS/TCP通訊協(xié)議，但在實(shí)際的應(yīng)用中我們會發(fā)現(xiàn)MODBUS/TCP協(xié)議確實(shí)達(dá)到了數(shù)據(jù)傳輸?shù)目煽啃砸螅诮⒕W(wǎng)絡(luò)連接時首先要進(jìn)行三次握手，對數(shù)據(jù)進(jìn)行封裝、傳輸，當(dāng)監(jiān)控中心收到信息時再返回一個確認(rèn)信息，在這一系列過程中，MODBUS/TCP協(xié)議花費(fèi)了大量的時間，因此也無法達(dá)到人們對數(shù)據(jù)的實(shí)時性傳輸?shù)囊蟆ａ槍ㄖh(huán)境通信的特點(diǎn)和以上問題，本文中采用MoDBUS/UDP協(xié)議。MODBUS/UDP協(xié)議，是將MODBUS協(xié)議與以太網(wǎng)UDP協(xié)議結(jié)合形成的，UDP協(xié)議是面向非連接的，其實(shí)時性高，通信效果好。UDP的實(shí)時性主要是在一個完整的周期通訊中，報文總的傳輸延遲減小，網(wǎng)絡(luò)的利用率提高，節(jié)點(diǎn)的響應(yīng)速度也就隨之得到了提升，因此能完成數(shù)據(jù)的實(shí)時傳輸。對于協(xié)議的可靠性、雖然不能從協(xié)議本身進(jìn)行改進(jìn)，但通過編寫好上層軟件，依然可以彌補(bǔ)MODBUS/UDP協(xié)議的不足。UDP具有TCP所望塵莫及的速度優(yōu)勢，盡管TCP協(xié)議中有各種安全保障功能，但是在實(shí)際執(zhí)行的過程中占用了大量的系統(tǒng)資源，從而對傳輸速度產(chǎn)生嚴(yán)重影響。
將一組數(shù)據(jù)從傳感器傳輸?shù)娇刂破骰驈目刂破鱾鬏數(shù)綀?zhí)行器，導(dǎo)致數(shù)據(jù)延時的因素主要有數(shù)據(jù)的封裝等待時延Twsit，從傳感器到控制器的網(wǎng)絡(luò)時延Tsc，控制器到執(zhí)行器的網(wǎng)絡(luò)時延Tca。也就是總時延T＝Twsit＋Tsc＋Tca，假若在網(wǎng)絡(luò)不擁堵的情況下，對比UDP和TCP的數(shù)據(jù)傳輸時延，我們會發(fā)現(xiàn)TCP所用的時間要比UDP的長，主要是因為在封裝數(shù)據(jù)時TCP協(xié)議要在數(shù)據(jù)中添加以太網(wǎng)幀頭和以太網(wǎng)幀尾，這就延長了Twsit的時間。在MODBUS協(xié)議中具有讀寫線圈、讀寫寄存器、讀寫異常等功能，因此我們就可以省去診斷、讀取記錄、編程等設(shè)備控制碼，節(jié)省了時間，使得傳輸過程的總時延減小，提高了控制中對實(shí)時性的要求。
MODBUS協(xié)議定義了一個與基礎(chǔ)通信層無關(guān)的PDU(協(xié)議數(shù)據(jù)單元)。特定總線或網(wǎng)絡(luò)上的MODBUS協(xié)議映射能夠在ADU(應(yīng)用數(shù)據(jù)單元)上引入附加域。
標(biāo)準(zhǔn)的MODBUS報文協(xié)議幀的地址域為1字節(jié)大小，為了能在網(wǎng)絡(luò)控制總線上采用令牌總線的方式來使得每個站點(diǎn)都有均等的機(jī)會來發(fā)送數(shù)據(jù)，采用隱性令牌的方式來避免介質(zhì)訪問引發(fā)的沖突，將1字節(jié)的地址域擴(kuò)大為2字節(jié)，地址域分為1字節(jié)的目的地址和1字節(jié)的源地址，1字節(jié)的功能碼變?yōu)?字節(jié)。改進(jìn)后的幀格式如圖3所示。
目的地址是該幀的接受地址：源地址是發(fā)送幀的地址：狀態(tài)位則用來表示發(fā)送的幀是否被接收。網(wǎng)絡(luò)管理者給每個節(jié)點(diǎn)分配一個眭一的地址。每個站點(diǎn)監(jiān)視收到的每個報文幀的源地址，并為接收到的源地址設(shè)置一個 隱h生令牌寄存器，讓隱性令牌寄存器的值為收到的源地址加1、若隱性令牌寄存器的值與哪個站點(diǎn)的介質(zhì)訪問控制MAC地址相同時、該站點(diǎn)則發(fā)送數(shù)據(jù)，若沒有數(shù)據(jù)可發(fā)送則發(fā)送一個空幀，在網(wǎng)絡(luò)中沒有真正的令牌幀在網(wǎng)絡(luò)中傳輸，而是將令牌隱含在普通的數(shù)據(jù)中。UDP上的MODBUS的請求/響應(yīng)格式如圖4所示。
另外，報文中要加上專業(yè)的MAPH頭(Modbus Application ProtocolHeader)，以達(dá)到識別MODBUS應(yīng)用數(shù)據(jù)單元ADU的目的。報文頭為7個字節(jié)長度、包括：事務(wù)處理標(biāo)識符(Transaction Identifier)、協(xié)議標(biāo)識符(Protocol Identifier)、長度(Length Field)、單元標(biāo)識符(UnitIdentifier)。
事務(wù)處理標(biāo)識符：用于事務(wù)處理配對。在響應(yīng)中、MODBUS服務(wù)器復(fù)制請求的事務(wù)處理標(biāo)識符。
協(xié)議標(biāo)識符：用于系統(tǒng)內(nèi)的多路復(fù)用。通過值0識別MODBUS協(xié)議。
長度：長度域是下一個域的字節(jié)數(shù)，包括單元標(biāo)識符和數(shù)據(jù)域。
單元標(biāo)識符：專門用于以太網(wǎng)TCP/IP網(wǎng)絡(luò)和MODBUS串行鏈路之間的網(wǎng)關(guān)對MODBUS或MODBUS＋串行鏈路從站的通信。
實(shí)驗結(jié)果分析
在LABVEIW軟件平臺上進(jìn)行了模擬實(shí)驗，對MODBUS/UDP傳輸數(shù)據(jù)流進(jìn)行檢測，MODBUS/UDP協(xié)議進(jìn)行數(shù)據(jù)傳輸時的數(shù)據(jù)流量在242Kbps到250Kbps之間。其原理圖與結(jié)果如圖5和圖6所示。
當(dāng)發(fā)送端的連接建立起來后，將正弦信號輸入數(shù)據(jù)類型轉(zhuǎn)換器，將轉(zhuǎn)換后的數(shù)據(jù)發(fā)送到UDP端口，UDPwrite根據(jù)所設(shè)置的傳輸端口對數(shù)據(jù)進(jìn)行傳輸。在接收端UDP read根據(jù)主機(jī)端口號讀取數(shù)據(jù)、在讀取數(shù)據(jù)過程中為能監(jiān)控到數(shù)據(jù)的傳輸流量，在接收處的傳輸末端使用框圖來顯示對數(shù)據(jù)的監(jiān)控情況。
為了進(jìn)行比較，對同一組隨機(jī)數(shù)據(jù)的傳輸也使用了MODBUS/TCP協(xié)議。流量監(jiān)控數(shù)據(jù)在236Kbps在245Kbps之間，我們不難發(fā)現(xiàn)MODBUS/TCP的傳輸速率明顯要比MODBUS/UDP低。導(dǎo)致這種現(xiàn)象的原因在第三部分已經(jīng)給出了分析，在LABVEIW上進(jìn)行模擬仿真不存在現(xiàn)實(shí)中Tsc和Tca時延的問題，因此進(jìn)一步證明了MODBUS/UDP在封裝部分時間短，占用網(wǎng)絡(luò)資源少，能快速對采集到的數(shù)據(jù)進(jìn)行傳輸。
結(jié)果表明，上位機(jī)使用MODBUS/UDP協(xié)議對測控終端進(jìn)行查詢并讀取終端的數(shù)據(jù)，MODBUS/UDP具有更好的實(shí)時性，因此對于有大量數(shù)據(jù)進(jìn)行傳輸時會減少堵塞問題的出現(xiàn)，因此使用MODBUS/UDP能實(shí)現(xiàn)數(shù)據(jù)高效和實(shí)時的傳輸。
udp協(xié)議范文5
【關(guān)鍵詞】HTTP2Sock，Sock2HTTP，隧道
1 引言
基于SIP協(xié)議的即時通信系統(tǒng)在企事業(yè)單位使用較多，而隨著單位保密意識的提高，對數(shù)據(jù)安全和網(wǎng)絡(luò)安全的重視，人們對防火墻訪問規(guī)則等安全策略的要求越來越嚴(yán)格，同時也限制了其基于計算機(jī)的各種應(yīng)用，阻礙了其業(yè)務(wù)的發(fā)展。本文采用HTTP Tunnel實(shí)現(xiàn)對防火墻的穿越，將TCP、UDP等非HTTP數(shù)據(jù)類型進(jìn)行HTTP偽裝和加密，在不改變單位的防火墻等安全策略的前提下，以隱蔽通信的方式完成應(yīng)用程序的數(shù)據(jù)傳輸。
本文重點(diǎn)探討了HTTP Tunnel技術(shù)在以SIP協(xié)議為基礎(chǔ)的即時通信系統(tǒng)中的應(yīng)用，并提出相應(yīng)解決方案和參考應(yīng)用框架。旨在提升HTTP Tunnel技術(shù)的應(yīng)用范圍，加強(qiáng)應(yīng)用業(yè)務(wù)的數(shù)據(jù)安全與網(wǎng)絡(luò)安全。
2 應(yīng)用系統(tǒng)框架
HTTP Tunnel被稱之為HTTP暗道，原理是將數(shù)據(jù)偽裝成 HTTP的數(shù)據(jù)形式來穿過防火墻。
基于SIP協(xié)議的即時通信系統(tǒng)是以SIP為信令交互協(xié)議的即時通信系統(tǒng)，其應(yīng)用包括HTTP訪問、即時消息、語音通信、視頻通信等。該系統(tǒng)通過HTTP Tunnel可以不用改變防火前的安全策略，即可實(shí)現(xiàn)自由通信。其框架基本包括四個主要方面：
1） 基于SIP協(xié)議的即時通信系統(tǒng)，該系統(tǒng)實(shí)現(xiàn)基于TCP、UDP、HTTP等協(xié)議的即時通信功能；
2） Sock2HTTP服務(wù)器，該服務(wù)器實(shí)現(xiàn)非HTTP協(xié)議數(shù)據(jù)包的HTTP格式轉(zhuǎn)換，通信端口映射，擁塞控制等功能；
3） HTTP Tunnel系統(tǒng)，該系統(tǒng)實(shí)現(xiàn)基于HTTP協(xié)議的雙向的虛擬數(shù)據(jù)連接，從而穿越防火墻；
4） HTTP2Sock服務(wù)器，該服務(wù)器實(shí)現(xiàn)需要轉(zhuǎn)換為其他格式的HTTP數(shù)據(jù)，通信端口的映射，擁塞控制等。
其拓?fù)鋱D如圖1：
圖1.基于SIP協(xié)議的即時通信系統(tǒng)的HTTP Tunnel應(yīng)用
3應(yīng)用系統(tǒng)設(shè)計
3.1基于SIP協(xié)議的即時通信系統(tǒng)
基于SIP協(xié)議的即時通信系統(tǒng)主要有兩部分組成。OpenSIPS服務(wù)器和oSIP客戶端。
3.1.1 OpenSIPS
OpenSIPS是成熟的開源SIP服務(wù)器，結(jié)構(gòu)非常靈活，其核心路由功能完全通過腳本來實(shí)現(xiàn)，可靈活定制各種路由策略，可靈活應(yīng)用于語音、視頻通信、IM以及Presence等多種應(yīng)用。
其主要功能如下：
SIP注冊服務(wù)器/服務(wù)器/重定向服務(wù)器
SIP presence agent
SIP IM Server
3.1.2 oSIP
oSIP是使用標(biāo)準(zhǔn)c編寫的SIP協(xié)議棧。
主要包括兩部分的內(nèi)容：狀態(tài)機(jī)模塊、解析器模塊。
狀態(tài)機(jī)模塊的功能：完成對某個事務(wù)（注冊過程，呼叫過程等等）狀態(tài)記錄，并在特定狀態(tài)下觸發(fā)相應(yīng)的事件或回調(diào)函數(shù)。
解析器模塊的功能：該模塊主要完成對SIP消息結(jié)構(gòu)剖析、SDP消息的結(jié)構(gòu)剖析以及URI結(jié)構(gòu)的剖析；
圖2.oSIP結(jié)構(gòu)
oSIP為SIP協(xié)議的客戶端，OpenSIPS為SIP協(xié)議的服務(wù)器，二者共同搭建基于SIP協(xié)議的即時通信系統(tǒng)。
3.2 Sock2HTTP服務(wù)器和HTTP2Sock服務(wù)器
當(dāng)位于內(nèi)網(wǎng)的SIP終端訪問外網(wǎng)，則終端建立連接的端口不一定被防火墻開放，尤其是UDP端口，若使TCP與UDP等消息穿越防火墻則需要相應(yīng)的協(xié)議轉(zhuǎn)換服務(wù)器，即Sock2HTTP和HTTP2Sock。
圖3.Sock2HTTP與HTTP2Sock
3.2.1功能描述
主要負(fù)責(zé)分配對應(yīng)的UDP端口；接收HTTP消息、解碼、以UDP的形式發(fā)送至目的地址；接收UDP消息、編碼、接收終端分配UDP端口的HTTP消息，返回生成的UDP端口；UDP端口與終端的對應(yīng)管理機(jī)制。
3.2.2設(shè)計說明
a．建立TCP套接字，與某端口綁定（可配置），監(jiān)聽該端口；
b．接收到請求后，fork子進(jìn)程處理該請求,請求包括要求分配端口的請求和其他請求兩類；
c．處理要求分配端口的請求，將分配的端口返回給終端，保持該TCP鏈接不斷開，直至通話結(jié)束或者終端注銷。
4結(jié)論
基于SIP協(xié)議的即時通信系統(tǒng)使用HTTP Tunnel技術(shù)，在企事業(yè)單位網(wǎng)內(nèi)外實(shí)現(xiàn)自由通信。該應(yīng)用不僅提升HTTP Tunnel技術(shù)的應(yīng)用范圍，更加強(qiáng)應(yīng)用業(yè)務(wù)的數(shù)據(jù)安全與網(wǎng)絡(luò)安全。系統(tǒng)采用分布式設(shè)計，為系統(tǒng)升級和集成提供很好的構(gòu)架基礎(chǔ)，是企事業(yè)單位業(yè)務(wù)和數(shù)據(jù)穿越防火墻的一種安全和高效的應(yīng)用。
參考文獻(xiàn)
[1] RFC 2543 3261SIP: Session Initiation Protocol.
[2] RFC 2616Hypertext Transfer Protocol -- HTTP/1.1.
udp協(xié)議范文6
關(guān)鍵詞：NAT；UDP Hole Punching；完全P2P；FSN
0 引言
網(wǎng)絡(luò)地址轉(zhuǎn)換協(xié)議(NAT：Network Address Translation)，通過將局域網(wǎng)上的主機(jī)地址映射為Internet上的合法IP地址，從而實(shí)現(xiàn)網(wǎng)絡(luò)地址復(fù)用。NAT對解決當(dāng)前IP地址短缺問題、構(gòu)建防火墻、保證網(wǎng)絡(luò)安全等都發(fā)揮了重要作用。但是隨著基于Internet的P2P網(wǎng)絡(luò)技術(shù)的廣泛應(yīng)用，更多的內(nèi)網(wǎng)主機(jī)需要參與到P2P中來。NAT協(xié)議下的主機(jī)IP地址(私網(wǎng)IP地址)在Internet上是不可見的，Internet上的主機(jī)不能主動訪問這些NAT協(xié)議下的主機(jī)，而位于不同NAT協(xié)議下的主機(jī)間更是無法相互識別而不能直接交換信息。但是P2P網(wǎng)絡(luò)要求任何主機(jī)之間都能夠直接對等交換信息，因此P2P網(wǎng)絡(luò)應(yīng)用必須解決穿越NAT實(shí)現(xiàn)雙向?qū)Φ韧ㄐ诺膯栴}。
本文將重點(diǎn)圍繞著Cone NAT穿越的完全P2P通信方法展開研究。
1 網(wǎng)絡(luò)地址轉(zhuǎn)換(NAT)的類型劃分
按照端口號轉(zhuǎn)換與否，NAT可以分為以下兩種：
(1)Basic NAT：將私網(wǎng)主機(jī)的私有IP地址轉(zhuǎn)換成公網(wǎng)IP地址，但并不轉(zhuǎn)換TCP/UDP端口信息。
(2)Network Address Port Translation(NAPT)：NAPT將單獨(dú)的公網(wǎng)IP地址和內(nèi)部多臺主機(jī)進(jìn)行綁定，當(dāng)不同的內(nèi)部主機(jī)和外部通信時，NAT不僅將內(nèi)部主機(jī)的私有IP轉(zhuǎn)換為公網(wǎng)IP，而且連端口號一起轉(zhuǎn)換。
按照端口號的分配情況，NAPT又可以分為以下兩種：
(1)Symmetric NAT：當(dāng)同一個內(nèi)部主機(jī)向不同的外網(wǎng)主機(jī)發(fā)起多個會話時，Symmetric NAT為這些會話分配不同的端口，Symmetric NAT能夠區(qū)別多個不同的會話并進(jìn)行地址轉(zhuǎn)換。
(2)Cone NAT：與Symmetric NAT不同，當(dāng)同一個內(nèi)部主機(jī)向不同的外網(wǎng)主機(jī)發(fā)起多個會話時，Cone NAT為這些會話分配同一個端口，并通過判斷數(shù)據(jù)包的來源(即反饋數(shù)據(jù)包中的IP地址和端口)來維持會話。所分配的同一個端口在所有會話結(jié)束后才收回。
由于當(dāng)前的NAT幾乎都是Cone NAT，所以本文只是基于Cone NAT進(jìn)行了研究，后面出現(xiàn)的NAT要是不特別說明，指的是Cone NAT。
2 P2P節(jié)點(diǎn)穿越Cone NAT方法
UDP是簡單的傳輸協(xié)議，幾乎不提供可靠性措施，是無連接的協(xié)議，但是效率非常高。不像TCP協(xié)議，傳輸數(shù)據(jù)之前要建立一種虛擬的連接關(guān)系，它只要知道對方的IP地址和UDP端口，就可以進(jìn)行數(shù)據(jù)傳輸。在P2P網(wǎng)絡(luò)中，采用UDP方式進(jìn)行數(shù)據(jù)傳輸，所以能夠獲得主機(jī)的Internet合法IP地址就可以進(jìn)行數(shù)據(jù)交換。
P2P的兩個節(jié)點(diǎn)分布有以下幾種情況：
(1)兩個節(jié)點(diǎn)都有自己的公網(wǎng)地址。
(2)兩個節(jié)點(diǎn)都使用同一個Cone NAT。
(3)一個節(jié)點(diǎn)有公網(wǎng)地址，另外一個節(jié)點(diǎn)使用一個ConeNAT協(xié)議。
(4)兩個節(jié)點(diǎn)使用不同的Cone NAT。
下面就對兩個P2P節(jié)點(diǎn)在不同內(nèi)網(wǎng)下，穿越NAT的User Datagram Protocol(UDP)Hole Punching方法進(jìn)行介紹。
如圖1所示，假設(shè)兩臺主機(jī)A和B處于不同的Cone NAT協(xié)議下。它們穿越NAT進(jìn)行直接通信的過程如下：