udp協(xié)議篇1
關(guān)鍵詞：UDP協(xié)議；Socket；網(wǎng)絡(luò)通信
中圖分類號：TP393文獻標識碼：A文章編號：1009-3044(2008)34-1867-02
Socket Network Programs Based on UDP Protocol
ZHOU Li-juan
(College of Science, Hunan University of Technology, Zhuzhou 412008, China)
Abstract: Windows Socket is a network programming interface,and applications can correspond to eachother in different domains without worrying about the different protocols by using it.This paper introduces the mechanism and principle of Socket network programs based on UDP protocol,and proposes a method of network with Java socket.
key words: UDP protocol;socket; network communication
Socket適用于網(wǎng)絡(luò)環(huán)境中的進程間通信，它已成為當前許多操作系統(tǒng)的網(wǎng)絡(luò)API，也是網(wǎng)絡(luò)操作系統(tǒng)中必不可少的基礎(chǔ)功能。隨著Linux操作系統(tǒng)和Internet的不斷發(fā)展，Linux網(wǎng)絡(luò)環(huán)境下尤其是基于UDP的socket通信技術(shù)仍廣為注目。文章介紹了socket的編程原理，并通過一個Java編寫的客戶/服務(wù)器程序，描述了網(wǎng)絡(luò)中基于UDP的不同主機上的兩個進程之間的socket通信機制。
1 Socket通信機制
Socket（套接字）機制是一種API，是網(wǎng)絡(luò)應(yīng)用程序的編程接口。Socket是通過標準文件描述符和其它程序通訊的一個方法。每一個套接字都用一個半相關(guān)描述：{協(xié)議，本地地址、本地端口}來表示；一個完整的套接字則用一個相關(guān)描述：{協(xié)議，本地地址、本地端口、遠程地址、遠程端口}，每一個套接字都有一個本地的由操作系統(tǒng)分配的唯一的套接字號。
根據(jù)傳輸數(shù)據(jù)類型的不同，Socket主要分為三類：1) 流式Socket（SOCK_STREAM），在這種方式下，兩個通訊的應(yīng)用程序之間要先建立一種虛擬的連接，提供可靠的、面向連接的通信流，它使用TCP協(xié)議，從而保證了數(shù)據(jù)傳輸?shù)恼_性和順序的。2) 數(shù)據(jù)報Socket（SOCK_DGRAM），它使用數(shù)據(jù)報協(xié)議UDP，定義了一種無連接的服務(wù)，數(shù)據(jù)通過相互獨立的報文進行傳輸，是無序的，并且不保證可靠、無差錯。3) 原始Socket，原始套接字允許對底層協(xié)議如IP或ICMP直接訪問，它功能強大但使用較為不便，主要用于一些協(xié)議的開發(fā)。
2 UDP協(xié)議的工作原理
UDP協(xié)議是一個面向無連接的協(xié)議，其連接的建立不必像TCP那樣需要服務(wù)器端偵聽，也不需要有客戶機請求連接，屬于一種“強制”性的網(wǎng)絡(luò)連接。UDP提供一對一或一對多的、無連接的數(shù)據(jù)報服務(wù)。該服務(wù)對消息中傳輸?shù)臄?shù)據(jù)提供不可靠的、最大努力的傳送，這意味著它不保證數(shù)據(jù)的到達，也不保證所傳送的數(shù)據(jù)報的順序是否正確，UDP不重新傳輸丟失的數(shù)據(jù)。其主要工作是：將應(yīng)用程序傳輸過來的數(shù)據(jù)分塊交給網(wǎng)絡(luò)層，確認接受到分組信息。
盡管UDP無法像TCP一樣提供可靠的數(shù)據(jù)傳輸，但UDP并不比TCP缺乏優(yōu)越性。UDP在傳輸效率方面比TCP要高一些，而且許多應(yīng)用程序并不需要保證嚴格的傳輸可靠性，比如視頻會議系統(tǒng)等，需要實時的交互，但并不要求音頻視頻的絕對正確。
使用UDP協(xié)議傳輸數(shù)據(jù)時，首先設(shè)置客戶計算機的Local Port(本地端口)屬性，而作為服務(wù)器的計算機只需要設(shè)置Remoter Host(遠程主機)屬性為客戶計算機的IP地址或域名即可，并將其Remote Port屬性設(shè)置為客戶計算機上的Local Port屬性。使用UDP端口號時，端口提供了用于發(fā)送消息的位置，每個端口由一個唯一的編號來標識。當應(yīng)用程序向另一臺計算機發(fā)送數(shù)據(jù)時，UDP生成一個數(shù)據(jù)頭，包括源端口，這些端口提供送達信息所需要的地址。UDP協(xié)議還為數(shù)據(jù)和數(shù)據(jù)頭計算出求和檢驗的值，在目標計算機中，數(shù)據(jù)包被傳遞至UDP協(xié)議程序并送到目的地端口。
3 UDP套接字的通信過程
中提供了兩個類DatagramSocket和DatagramPacket用來支持數(shù)據(jù)報通信。DatagramSoc ket用來在程序之間建立傳送數(shù)據(jù)報的通信連接，是數(shù)據(jù)報通信中的Socket。在數(shù)據(jù)報實現(xiàn)C/S通信程序時，無論在客戶端還是服務(wù)器端，都要首先建立一個DatagramSocket對象，用來表示數(shù)據(jù)報通信的端點，應(yīng)用程序通過Socket接收或發(fā)送數(shù)據(jù)報。
DatagramPacket則用來表示一個數(shù)據(jù)報，它是傳輸數(shù)據(jù)的載體，封裝了數(shù)據(jù)、數(shù)據(jù)長度、數(shù)據(jù)報地址等信息。
采用UDP套接字方式實現(xiàn)C/S的通信程序由客戶端和服務(wù)器端兩部分組成。服務(wù)器進程依次按以下步驟進行：1) 調(diào)用Socket()創(chuàng)建一個數(shù)據(jù)報套接字；2) 調(diào)用bind()把服務(wù)器地址綁定在該套接字上；3) 調(diào)用recvform()等待客戶進程發(fā)來的請求，服務(wù)器此時處于無限循環(huán)狀態(tài)；4) 服務(wù)進程接收到客戶進程所發(fā)來的數(shù)據(jù)報后，進行處理，調(diào)用sendto()將處理結(jié)果返回給客戶進程，返回狀態(tài)3)，繼續(xù)監(jiān)聽；5)服務(wù)進程調(diào)用close()撤消套接字，終止服務(wù)。
客戶進程則按以下步驟進行：1) 調(diào)用Socket()創(chuàng)建一個數(shù)據(jù)流套接字；2) 調(diào)用sendto()向服務(wù)器進程發(fā)送數(shù)據(jù)報；3) 調(diào)用recvfrom()等待服務(wù)器進程返回該處理結(jié)果；4) 客戶進程調(diào)用close()撤消套接字。
4 數(shù)據(jù)報通信實例
程序由服務(wù)器端和客戶端兩部分組成，服務(wù)器端主機中有一個名為“udp_socket.txt”文件，文件中保存了一段英文。服務(wù)器端接收一個客戶端的請求，就從文件中讀取若干個英文字符發(fā)送給客戶端。當文件中所有內(nèi)容發(fā)送給完畢，服務(wù)器端程序?qū)⑼顺觥？蛻舳耸紫葮?gòu)造一個數(shù)據(jù)報發(fā)送給服務(wù)器端，然后等待接受服務(wù)器端響應(yīng)，當接收到服務(wù)器端的數(shù)據(jù)報后，顯示數(shù)據(jù)并結(jié)束通信。
1) 服務(wù)器端程序
public class Server_Th
{ boolean m_q=true;
public void serverWork() throea IOException
{DatagramSocket ds=new DatagramSocket(2000)
//創(chuàng)建端口號為2000的數(shù)據(jù)報套接字
BufferedReader in=new BufferedReader(new FileReader (“udp_socket.txt”));
while(m_q)
{ byte buf[ ]=new byte[256];//創(chuàng)建緩沖區(qū)
DatagramPacket packet=new DatagramPacket (buf, buflength); //創(chuàng)建接收數(shù)據(jù)報對象
ds.receive(packet);//接收數(shù)據(jù)報
String dString=null;
if((dString=in.reaLine())==null)
{in.close();
m_q=false;
dString=”Good Morning!”;}
buf=dString.getBytes();//將數(shù)據(jù)存儲到buf中
inetAddress address=packet.getAddress();
//得到客戶端IP地址
int prot=packet.getPort();//得到客戶端的端口
packet=new DatagramPacket (buf,buf.length, address. port );
//構(gòu)造要發(fā)送數(shù)據(jù)報
ds.send(packet);//發(fā)送數(shù)據(jù)報
}
ds.close();//關(guān)閉
}
public void main(String args[])
{ Server_Th server=new Server_Th();
try
{server.serverWork();}
Catch(IOException e){}
}}
2) 客戶端程序
public class Client_Th
{public void main(String args[ ]) throws IOException
{ DatagramSocket socket=new DatagramSocket( );
//創(chuàng)建套接字對象
byte buf[ ]=new byte[256];
InetAdress address=InetAddress.getByName(“20.14.30.9”);
//服務(wù)器IP地址
DatagramPacket packet=new DatagramPacket(buf,buf. Length,address,2000);//創(chuàng)建要發(fā)送的數(shù)據(jù)報對象
socket.send(packet);//接收數(shù)據(jù)報
packet=new DatagramPacket(buf,buf.length);
//創(chuàng)建要接收的數(shù)據(jù)報對象
socket.receive(packet);//接收數(shù)據(jù)報
String received=new String(packet.getData());
System.out.println(“The string form the server: ”+recerived);
//取得數(shù)據(jù)報中的數(shù)據(jù)并顯示
Socket.close();//關(guān)閉socket
}}
編寫程序時客戶端和服務(wù)器端的DatagramSocket必須用一個端口，因為客戶端向服務(wù)器端請求時，服務(wù)器需要知道從哪個端口監(jiān)聽請求。當數(shù)據(jù)進行傳輸時，服務(wù)器從接收到的數(shù)據(jù)報中得到客戶端的接收數(shù)據(jù)的端口，然后將數(shù)據(jù)報發(fā)送到這個端口，客戶端則監(jiān)聽這個端口而得到服務(wù)器端發(fā)送過來的數(shù)據(jù)報并顯示其內(nèi)容。運行時要先運行服務(wù)器端程序，再運行客戶端程序。
5 小結(jié)
Socket在網(wǎng)絡(luò)編程方面發(fā)揮著很大的作用。UDP是可靠性無法得到保障的協(xié)議，但對于質(zhì)量要求不是很高的網(wǎng)絡(luò)應(yīng)用程序，UDP是一個很好的選擇。
參考文獻：
[1] 張桂珠.Java面向?qū)ο蟪绦蛟O(shè)計[M].北京:郵電出版社,2006.
[2] 周坤,傅德勝.基于Windows Socket的網(wǎng)絡(luò)數(shù)據(jù)傳輸及其安全[J].計算機工程與設(shè)計,2007,28(22):5381-5386.
[3] 趙文清.淺析用Socket的Java語言網(wǎng)絡(luò)通訊機制和程序設(shè)計[J].信息技術(shù),2002(7):66-67.
udp協(xié)議篇2
關(guān)鍵詞：arm；linux；交叉編譯環(huán)境；udp協(xié)議；重發(fā)機制；重發(fā)次數(shù)
中圖分類號：tp393文獻標識碼：a文章編號：1009-3044(2011)13-3001-03
the application research of communicating based on arm-linux environment and udp-protocol
cui hao, shao ping-fan
(wuhan university of science and technology, wuhan 430000, china)
abstract: the sender and receiver are relatively independent when communicating under udp- protocol, the sender resending messages to receiver times instead of creating a connection. a resend-mechanism that the key-messages were send by upper computer in fixed times, was used in order to ensuring not to lost key-message. although the resend-mechanism can ensure that the key-message wouldn’t be lose anyway, but abundant of redundancy messages were send through the network device lead to inefficency, obviously more resend-times more inefficency. so, how to determine the resend-times become the crucial to improve the efficiency while ensuring the messages were send accurately. a method of determining the resend-times will be given as following.
key words: arm; linux; crossing compile evironment; udp-protocol; resend mechanism; resend times
udp協(xié)議以其高效性和應(yīng)用的簡單，被廣泛運用于嵌入式網(wǎng)絡(luò)開發(fā)中。由于udp協(xié)議的應(yīng)用簡單，在嵌入式設(shè)備開發(fā)過程中，網(wǎng)絡(luò)資源的利用率并不高。以下將介紹一個udp具體項目實驗過程，描述arm-linux環(huán)境的軟硬件環(huán)境構(gòu)建過程，并對udp協(xié)議下一種重發(fā)模式中上位機的重發(fā)次數(shù)的確定提出一種可行的方法。
1 研究背景
隨著嵌入式技術(shù)的快速發(fā)展，嵌入式設(shè)備已經(jīng)在許多領(lǐng)域取代了傳統(tǒng)的微型機設(shè)備。本文的選題主要來自于實習期間承接的一項改造項目：某院校特長生評分系統(tǒng)的改造。項目改造目的有：1) 保留原上位機。2) 改用手持式客戶端進行顯示及評分操作。3)保留原有網(wǎng)絡(luò)設(shè)備。針對要求，我們使用s3c2440作為硬件平臺，移植linux操作系統(tǒng)，并在arm-linux環(huán)境下研究了udp協(xié)議的通信過程，進行了上位機與嵌入式系統(tǒng)的udp協(xié)議通信實驗及分析，并給出一種重發(fā)機制中的發(fā)送次數(shù)求法。
2 硬件平臺介紹
s3c2440處理速度達到了400mhz，具有較高的性價比。為了提高開發(fā)效率，我們采用公司自行研制開發(fā)的et-s3c2440開發(fā)板。
2.1 et-s3c2440開發(fā)板簡介
et-s3c2440是公司自行開發(fā)的一款arm9架構(gòu)的實驗開發(fā)板，其結(jié)構(gòu)框圖如圖1。
核心板的主要器件有：32mb×2片sdram，64mb norflash，512mb nandflash。設(shè)計了啟動方式可選，通過開關(guān)選擇從nandflash或norflash啟動。
2.2 實驗相關(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)用程序在硬件平臺上運行起來。以下是對嵌入式linux操作系統(tǒng)移植的過程。
3.1 交叉編譯環(huán)境的構(gòu)建
linux 2.6.29.1版本的內(nèi)核可以登錄到kernel.org下載。本文選擇的是arm-linux-gcc-4.3.2工具鏈(ftp://ftp.arm.linux.org.uk/pub/armlinux/toolchain)
在宿主機上進入linux系統(tǒ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是一款相當成熟和相對簡單的常用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, “自定義機器名”)，修改nandflash分區(qū)信息(arch/arm/plat-s3c24xx/common-smdk.c結(jié)構(gòu)體static struct mtd_partition smdk_default_nand_part[]中保存的是nandflah的分區(qū)信息，將其修改為當前使用的分區(qū)信息),然后修改nandflash的匹配時間(3c2410_platform_nand_smdk_nand_info smdk_nand_info ={})。
上述內(nèi)核源代碼修改完成后，還需要對一些設(shè)備的驅(qū)動進行修改。本文使用的nec 3.5寸 320×240液晶屏，硬件平臺使用gpg4腳進行背光控制，需要修改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)資源很豐富，本文也不再贅述。
本實驗中nandflash采用的是yaffs2文件系統(tǒng)，所以打yaffs2文件系統(tǒng)補丁，壓縮包為cvs-root.tar.gz。
至此，linux的內(nèi)核源代碼修改工作完成了，下面還需要利用makefile,進行內(nèi)核配置。
在linux 2.6.29.1內(nèi)核目錄下首先make s3c2410_defconfig使用2410的配置模板來配置2440；然后make menuconfig,這時我們可以在圖形化界面中，空格鍵可改變各個配置選項的被選中狀態(tài)，根據(jù)需要進行配置即可。配置完成后保存好配置，最后進行內(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)核工作運行正常。
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進行配置，然后對busybox進行編譯(make config_prefix=/opt/studyarm/rootfs install)，在目標目錄下會生成目錄bin、sbin、usr和文件linuxrc的內(nèi)容。
基本目錄結(jié)構(gòu)生成后，應(yīng)該在目標目錄下建立一些未生成的必要的系統(tǒng)目錄如dev、etc、lib等，并通過chmod命令改變目錄權(quán)限為可寫。再將一些必要的動態(tài)鏈接庫和靜態(tài)庫拷貝到lib下，然后在dev目錄下創(chuàng)建設(shè)備節(jié)點，最后創(chuàng)建該嵌入式linux系統(tǒng)的初始化配置文件(包括設(shè)備列表文件、口令、網(wǎng)絡(luò)分組組名、hostname主機名、etc/inittab初始化表單、etc/profile環(huán)境變量配置文件、用于系統(tǒng)初始化的.bash腳本文件等)。[2]由于本實驗需對網(wǎng)絡(luò)編程，要求自動初始化cs8900a網(wǎng)卡芯片的ip地址、網(wǎng)關(guān)、子網(wǎng)掩碼等，所以在開機自啟動腳本中加入ifconfig語句，使得開機時自動配置網(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é)議通信實驗
經(jīng)過上述硬件設(shè)計和操作系統(tǒng)移植過程，本文所使用到的實驗環(huán)境已經(jīng)構(gòu)建完畢，經(jīng)反復調(diào)試修改，嵌入式linux操作系統(tǒng)在平臺下運行正常，于是進行udp協(xié)議通信實驗。
4.1 udp協(xié)議套接字編程基礎(chǔ)
udp是一個面向數(shù)據(jù)報和無連接的簡單傳輸層協(xié)議，它不像tcp那樣通過握手過程建立服務(wù)器與客戶端的連接才可以工作。在網(wǎng)絡(luò)通信質(zhì)量較好的情況下，udp體現(xiàn)出高效率，這適合于傳送少量報文的應(yīng)用。[3] linux系統(tǒng)是通過套接字結(jié)構(gòu)來進行網(wǎng)絡(luò)編程的，應(yīng)用程序通過對套接字的幾個函數(shù)調(diào)用，會返回一個用于通信的套接字描述符,而linux應(yīng)用程序在進行任何形式的i/o操作時，程序?qū)嶋H上是在讀寫一個文件描述符。[4]因此linux下的套接字編程，可以看成是對普通文件描述符的操作，這些操作與被使用的硬件平臺無關(guān)，這是linux設(shè)備無關(guān)性的優(yōu)點。udp協(xié)議的通信模型如圖3所示。
在上述流程中，客戶端所收到的報文被存儲在緩沖區(qū)中，recvfrom()函數(shù)返回了報文存儲緩沖區(qū)的首地址，我們可以很方便地對這個首地址進行數(shù)組操作，從而實現(xiàn)對報文的解碼。
4.2 上位機報文結(jié)構(gòu)及重發(fā)機制分析
根據(jù)項目要求，上位機軟件依然保留，我們使用協(xié)議嗅探工具對上位機發(fā)送的報文進行了嗅探，得到了上位機報文的結(jié)構(gòu)如表1所示。
表1 上位機報文結(jié)構(gòu)
上位機發(fā)出的每條報文由32個字節(jié)組成，第0位為版本信息。第1……12位為比賽信息和運動員教練信息，是報文的關(guān)鍵信息部分，13……22位為服務(wù)器端和客戶端的ip地址及端口號信息，23位是上位機對客戶端的操作指令代碼，24位是相關(guān)重發(fā)機制的代碼，30和31兩位是checksum，用來保證數(shù)據(jù)傳輸?shù)恼_。上位機采用的重發(fā)機制是一種上位機按照固定重發(fā)次數(shù)多次發(fā)送同一關(guān)鍵內(nèi)容報文的機制，其第24位重發(fā)機制位被分為高4位和低4位兩部分，高四位的內(nèi)容是當前發(fā)送的報文的索引號，每次發(fā)送一條新內(nèi)容的報文時索引號自增1，索引號的取值范圍在0x00—0xff范圍內(nèi)循環(huán)自增。低四位是重發(fā)編號，表示同一索引號的報文正在被第幾次重發(fā)，固定的重發(fā)次數(shù)由上位機初始化時設(shè)定。
4.3 嵌入式客戶端的實驗程序設(shè)計
針對報文結(jié)構(gòu)，我們對接收端編寫實驗程序代碼，代碼的主要功能是從上位機接收報文，將計算出的checksum校驗和與收到的校驗和對比判斷報文是否正確，然后從正確報文中取出主要信息并按照報文中的上位機指令碼進行輸出。其結(jié)構(gòu)流程圖如圖3所示。
實驗程序經(jīng)編碼、調(diào)試后在交叉編譯環(huán)境中交叉編譯，生成arm-linux環(huán)境下可執(zhí)行文件，在目標板上執(zhí)行。經(jīng)測試試驗程序能夠正確接收上位機發(fā)來的報文，對報文解碼，并能根據(jù)上位機命令對關(guān)鍵信息做輸出處理。
4.4 對上位機重發(fā)次數(shù)的研究
進行udp協(xié)議通信時，發(fā)送端和接收端的狀態(tài)是相對獨立的，發(fā)送端不與接收端建立連接，而是不停向接收端發(fā)送，為了確保不丟失報文，上位機采取了按固定次數(shù)重發(fā)相同內(nèi)容報文的機制。然而這種機制雖然可以有效確保報文不丟失，但是大量冗余數(shù)據(jù)報被發(fā)送，網(wǎng)絡(luò)資源利用率不高。重發(fā)次數(shù)越多，冗余數(shù)據(jù)報越多，效率越低。要想有效保證數(shù)據(jù)報準確發(fā)送的同時又不產(chǎn)生過多冗余數(shù)據(jù)報，那么重復發(fā)送的次數(shù)的確定就成為問題的關(guān)鍵。以下給出一種確定上位機重發(fā)次數(shù)的方法。
假設(shè)當前網(wǎng)絡(luò)狀況下，每次報文發(fā)送被丟失的概率為p，系統(tǒng)允許接收端報文關(guān)鍵內(nèi)容丟失概率為q,那么如何確定以上重發(fā)機制中的重發(fā)次數(shù)k呢？
特殊情況下若報文重發(fā)次數(shù)為2，分別在每條報文重發(fā)機制位注明一個索引號和一個重發(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種，當x.1 , x.2丟失，此時索引號為x的報文關(guān)鍵信息將全部丟失。當x.2,(x+1). 1丟失，丟失報文的索引號不同，此時不會發(fā)生報文關(guān)鍵信息丟失，因此報文關(guān)鍵內(nèi)容丟失的概率q=p2/2。
當報文重發(fā)次數(shù)為3,依然在每條報文的重發(fā)機制位注明索引號和重發(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種，當x.1 , x.2 , x.3丟失，此時索引號為x的報文信息全部丟失。當x.2 , x.3 ,(x+1).1或x.3 ,(x+1).1 ,(x+1).2丟失時不影響報文的準確傳遞。因此此時報文關(guān)鍵內(nèi)容丟失的概率q=p3/3。
推廣至一般情況易得當報文重發(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) 求得兩圖像的交點的x坐標，并將x坐標值取整加一即為所求重發(fā)次數(shù)k。
本文實驗中，需求方允許報文關(guān)鍵信息丟失概率q=0.0001,我們分別對上位機發(fā)送端和下位機接收端收發(fā)的報文進行了統(tǒng)計，在某一固定時間段內(nèi)，上位機共發(fā)送報文19665條，接收端接收報文18636條，傳輸過程中丟失的報文19665-18636=1029條，當前網(wǎng)絡(luò)環(huán)境下的報文丟失率為，即p=0.0523。據(jù)此數(shù)值分別作出y=0.0001x的曲線和y=0.0523 x的曲線，取得兩曲線交點x坐標為x≈2.78，最后將x=2.78取整加1得到k=3，即上位機對同一數(shù)據(jù)報的重發(fā)次數(shù)應(yīng)該定為3次就可保證系統(tǒng)丟失報文的概率低于0.0001。
5 結(jié)論與展望
本文從硬件平臺搭建、linux移植以及udp協(xié)議編程幾個方面介紹了arm-linux環(huán)境下udp協(xié)議通信的具體實現(xiàn)，并分析了一種在實際嵌入式項目中常用的上位機數(shù)據(jù)報重發(fā)機制，最后對這種機制中的重發(fā)次數(shù)的確定方法給出了求解過程，為后續(xù)的具體項目實施提供了實踐依據(jù)，也希望為其他應(yīng)用這種重發(fā)機制的嵌入式產(chǎn)品開發(fā)者們提供了借鑒。
參考文獻：
[1] 李偉.基于arm9的嵌入式linux手持平臺的設(shè)計與實現(xiàn)[d].武漢:武漢理工大學碩士學位論文,2009.
[2] 范艷開.基于arm的嵌入式linux操作系統(tǒng)移植[d].西安:西北工業(yè)大學,2005.
[3] 劉暢,彭楚武.linux下的udp協(xié)議編程[j].儀表技術(shù),2006(1).
udp協(xié)議篇3
【關(guān)鍵詞】UDP協(xié)議；ARM；X86；通訊；解決方案
隨著人工智能的應(yīng)用，ARM產(chǎn)品已經(jīng)遍布到各個領(lǐng)域：工業(yè)控制、無線通訊領(lǐng)域、消費類電子產(chǎn)品、成像和安全產(chǎn)品，包括現(xiàn)在流行的數(shù)碼相機和打印機中絕大部分采用ARM技術(shù)，手機中的32位SIM智能卡也采用了ARM技術(shù)。除此以外，ARM微處理器及技術(shù)還應(yīng)用到許多不同的領(lǐng)域，并會在將來取得更加廣泛的應(yīng)用，因此，ARM與其它平臺之間通訊就顯得尤為重要。
1.UDP協(xié)議本質(zhì)
UDP協(xié)議是英文User Datagram Protocol的縮寫，即用戶數(shù)據(jù)報協(xié)議，主要用來支持那些需要在計算機之間傳輸數(shù)據(jù)的網(wǎng)絡(luò)應(yīng)用。包括網(wǎng)絡(luò)視頻會議系統(tǒng)在內(nèi)的眾多客戶/服務(wù)器模式的網(wǎng)絡(luò)應(yīng)用都需要使用UDP協(xié)議。UDP協(xié)議從問世至今已經(jīng)被使用了很多年，雖然其最初的光彩已經(jīng)被一些類似協(xié)議所掩蓋，但即使是在今天，UDP仍然不失為一項非常實用和可行的網(wǎng)絡(luò)傳輸層協(xié)議。
UDP協(xié)議使用端口號為不同的應(yīng)用保留其各自的數(shù)據(jù)傳輸通道。UDP和TCP協(xié)議正是采用這一機制實現(xiàn)對同一時刻內(nèi)多項應(yīng)用同時發(fā)送和接收數(shù)據(jù)的支持。數(shù)據(jù)發(fā)送一方（可以是客戶端或服務(wù)器端）將UDP數(shù)據(jù)報通過源端口發(fā)送出去，而數(shù)據(jù)接收一方則通過目標端口接收數(shù)據(jù)。有的網(wǎng)絡(luò)應(yīng)用只能使用預(yù)先為其預(yù)留或注冊的靜態(tài)端口；而另外一些網(wǎng)絡(luò)應(yīng)用則可以使用未被注冊的動態(tài)端口。因為UDP報頭使用兩個字節(jié)存放端口號，所以端口號的有效范圍是從0到65535。一般來說，大于49151的端口號都代表動態(tài)端口。
數(shù)據(jù)報的長度是指包括報頭和數(shù)據(jù)部分在內(nèi)的總的字節(jié)數(shù)。因為報頭的長度是固定的，所以該域主要被用來計算可變長度的數(shù)據(jù)部分（又稱為數(shù)據(jù)負載）。數(shù)據(jù)報的最大長度根據(jù)工作環(huán)境的不同而各異。從理論上說，包含報頭在內(nèi)的數(shù)據(jù)報的最大長度為65535字節(jié)。不過，一些實際應(yīng)用往往會限制數(shù)據(jù)報的大小，有時會降低到8192字節(jié)。
UDP協(xié)議使用報頭中的校驗值來保證數(shù)據(jù)的安全。校驗值首先在數(shù)據(jù)發(fā)送方通過特殊的算法計算得出，在傳遞到接收方之后，還需要再重新計算。
如果某個數(shù)據(jù)報在傳輸過程中被第三方篡改或者由于線路噪音等原因受到損壞，發(fā)送和接收方的校驗計算值將不會相符，由此UDP協(xié)議可以檢測是否出錯。其實在UDP協(xié)議中校驗功能是可選的，如果將其關(guān)閉可以使系統(tǒng)的性能有所提升。這與TCP協(xié)議是不同的，后者要求必須具有校驗值。
2.實現(xiàn)案例
實現(xiàn)案例如下：在觸摸屏進行畫圖，使其在液晶屏上顯示，同時通過網(wǎng)絡(luò)傳輸數(shù)據(jù)，使其在計算機屏幕上顯示，并由計算機控制清除液晶屏上的圖形。
步驟如下：
（1）新建工程
void InitNetWork（）//初始化網(wǎng)絡(luò)
{
U32 ipaddr32，ipmaskaddr32，ipgateaddr32；
U8 *Mac；
ipaddr32=Get_ipaddr（）； //獲取IP地址
ipmaskaddr32=Get_maskaddr（）；//獲取子網(wǎng)掩碼
ipgateaddr32=Get_gwaddr（）； //獲取網(wǎng)關(guān)
Mac=Get_mac（）； //獲取網(wǎng)卡地址
NetPortChoose（0）； //選擇網(wǎng)口，必須在配置網(wǎng)絡(luò)以前進行
initOSNet（ipaddr32， ipmaskaddr32， ipgateaddr32，Mac）；//配置網(wǎng)絡(luò)
OSTimeDly（1000）；//任務(wù)掛起1秒
printk（"init Ethernet and UDP is ok?。躰"）；
}
（3）定義計算機端套接字，全局變量
（4）編寫Main_Task任務(wù)及消息循環(huán)
主要負責響應(yīng)觸摸屏消息，在屏幕上畫圖，然后將數(shù)據(jù)傳輸?shù)接嬎銠C上。
對觸摸屏消息的處理和鍵盤消息類似，其消息類型pMsg->Message為OSM_TOUCH_SCREEN，消息參數(shù)pMsg->LParam中包含了觸摸屏的動作信息，定義如下：
#define TCHSCR_ACTION_NULL 0
#define TCHSCR_ACTION_CLICK 1 //觸摸屏單擊
#define TCHSCR_ACTION_DBCLICK 2 //觸摸屏雙擊
#define TCHSCR_ACTION_DOWN 3 //觸摸屏按下
#define TCHSCR_ACTION_UP 4 //觸摸屏抬起
#define TCHSCR_ACTION_MOVE 5 //觸摸屏移動
消息參數(shù)pMsg->WParam中則包含了觸摸點的坐標信息，低16位是X坐標值，高16位是Y坐標值。這里當觸摸屏產(chǎn)生“按下”動作后采用MoveTo（）函數(shù)設(shè)置繪圖起始點坐標，當產(chǎn)生“移動”動作后采用LineTo（）函數(shù)繪制線段。
3.解決方案
3.1 建立Socket
為了建立建立Socket，程序可以調(diào)用Socket函數(shù)，該函數(shù)返回一個類似于文件描述符的句柄。socket函數(shù)原型為：
int socket（int domain， int type，int protocol）；
domain指明所使用的協(xié)議族，通常為PF_INET，表示互聯(lián)網(wǎng)協(xié)議族（TCP/IP協(xié)議族）；type參數(shù)指定socket的類型：SOCK_STREAM或SOCK_DGRAM，Socket接口還定義了原始Socket（SOCK_RAW），允許程序使用低層協(xié)議；protocol通常賦值”0”。Socket（）調(diào)用返回一個整型socket描述符，你可以在后面的調(diào)用使用它。
Socket描述符是一個指向內(nèi)部數(shù)據(jù)結(jié)構(gòu)的指針，它指向描述符表入口。調(diào)用Socket函數(shù)時，socket執(zhí)行體將建立一個Socket，實際上”建立一個Socket”意味著為一個Socket數(shù)據(jù)結(jié)構(gòu)分配存儲空間。Socket執(zhí)行體為你管理描述符表。
兩個網(wǎng)絡(luò)程序之間的一個網(wǎng)絡(luò)連接包括五種信息：通信協(xié)議、本地協(xié)議地址、本地主機端口、遠端主機地址和遠端協(xié)議端口。Socket數(shù)據(jù)結(jié)構(gòu)中包含這五種信息。
3.2 配置Socket
通過socket調(diào)用返回一個socket描述符后，在使用socket進行網(wǎng)絡(luò)傳輸以前，必須配置該socket。面向連接的socket客戶端通過調(diào)用Connect函數(shù)在socket數(shù)據(jù)結(jié)構(gòu)中保存本地和遠端信息。無連接socket的客戶端和服務(wù)端以及面向連接socket的服務(wù)端通過調(diào)用bind函數(shù)來配置本地信息。
Bind函數(shù)將socket與本機上的一個端口相關(guān)聯(lián)，隨后你就可以在該端口監(jiān)聽服務(wù)請求。Bind函數(shù)原型為：
int bind（int sockfd，struct sockaddr *my_addr，int addrlen）；
Sockfd是調(diào)用socket函數(shù)返回的socket描述符，my_addr是一個指向包含有本機IP地址及端口號等信息的sockaddr類型的指針；addrlen常被設(shè)置為
3.3 建立連接
面向連接的客戶程序使用Connect函數(shù)來配置socket并與遠端服務(wù)器建立一個TCP連接，其函數(shù)原型為：
int connect（int sockfd，struct sockaddr *serv_addr，int addrlen）；
Sockfd是socket函數(shù)返回的socket描述符；serv_addr是包含遠端主機IP地址和端口號的指針；addrlen是遠端地址結(jié)構(gòu)的長度。Connect函數(shù)在出現(xiàn)錯誤時返回-1，并且設(shè)置errno為相應(yīng)的錯誤碼。進行客戶端程序設(shè)計無須調(diào)用bind（），因為這種情況下只需知道目的機器的IP地址，而客戶通過哪個端口與服務(wù)器建立連接并不需要關(guān)心，socket執(zhí)行體為你的程序自動選擇一個未被占用的端口，并通知你的程序數(shù)據(jù)什么時候到達端口。
Connect函數(shù)啟動和遠端主機的直接連接。只有面向連接的客戶程序使用socket時才需要將此socket與遠端主機相連。無連接協(xié)議從不建立直接連接。面向連接的服務(wù)器也從不啟動一個連接，它只是被動的在協(xié)議端口監(jiān)聽客戶的請求。
Listen函數(shù)使socket處于被動的監(jiān)聽模式，并為該socket建立一個輸入數(shù)據(jù)隊列，將到達的服務(wù)請求保存在此隊列中，直到程序處理它們。
int listen（int sockfd，int backlog）；
首先，當accept函數(shù)監(jiān)視的socket收到連接請求時，socket執(zhí)行體將建立一個新的socket，執(zhí)行體將這個新socket和請求連接進程的地址聯(lián)系起來，收到服務(wù)請求的初始socket仍可以繼續(xù)在以前的socket上監(jiān)聽，同時可以在新的socket描述符上進行數(shù)據(jù)傳輸操作。
3.4 傳輸數(shù)據(jù)
Send（）和recv（）這兩個函數(shù)用于面向連接的socket上進行數(shù)據(jù)傳輸。
Sockfd是你用來傳輸數(shù)據(jù)的socket描述符；msg是一個指向要發(fā)送數(shù)據(jù)的指針；Len是以字節(jié)為單位數(shù)據(jù)的長度；flags一般情況下設(shè)置為0（關(guān)于該參數(shù)的用法可參照man手冊）。
Send（）函數(shù)返回實際上發(fā)送出的字節(jié)數(shù)，可能會少于你希望發(fā)送的數(shù)據(jù)。在程序中應(yīng)該將send（）的返回值與欲發(fā)送的字節(jié)數(shù)進行比較。當send（）返回值與len不匹配時，應(yīng)該對這種情況進行處理。
3.5 傳輸結(jié)束
當所有的數(shù)據(jù)操作結(jié)束以后，你可以調(diào)用close（）函數(shù)來釋放該socket，從而停止在該socket上的任何數(shù)據(jù)操作。
udp協(xié)議篇4
關(guān)鍵詞 網(wǎng)絡(luò)通信；UDP二次封裝；共享內(nèi)存；進程間通信
中圖分類號TN92 文獻標識碼A 文章編號 1674-6708（2011）55-0181-02
1研究背景
磁浮仿真系統(tǒng)大致可以為分3個層次，底層是仿真子系統(tǒng)的仿真管理計算機，中間層是仿真支撐服務(wù)器，上層是工作站仿真計算機。所有環(huán)境仿真設(shè)備通過以太網(wǎng)與底層子系統(tǒng)的仿真管理計算機相連，仿真管理計算機對其仿真子系統(tǒng)進行統(tǒng)一管理，它將子系統(tǒng)仿真設(shè)備的工況信息實時向上推送。仿真支撐服務(wù)器與所有底層子系統(tǒng)管理計算機和上層工作站均有通信需求，是報文收發(fā)的中轉(zhuǎn)站，它將、工作站及其執(zhí)行結(jié)果的信息記入數(shù)據(jù)庫備查，或用于數(shù)據(jù)分析。上層工作站用于集成管理底層的子系統(tǒng)，它注入故障下達測試命令到底層子系統(tǒng)管理計算機并等待應(yīng)答。此外，底層子系統(tǒng)管理計算機之間也互相傳遞信息。這些計算機中仿真系統(tǒng)在處理接收和發(fā)送數(shù)據(jù)上的工作大多是相同的，如果能夠簡化它們在數(shù)據(jù)通信上的工作，將對系統(tǒng)的設(shè)計和效率有很大的提高作用。網(wǎng)絡(luò)通信方案的設(shè)計，即可將系統(tǒng)中各模塊處理網(wǎng)絡(luò)通信的部分抽取出來，封裝成一個相對獨立的模塊。
2影響因素分析
磁浮仿真系統(tǒng)中底層管理計算機上運行的仿真軟件是不同編程語言實現(xiàn)的，各自重新構(gòu)建通信接口有困難,底層、中層、上層不同計算機之間的通信要求也各異。通過對磁浮仿真系統(tǒng)中多個模塊的通信要求分析，可以得到模塊間的數(shù)據(jù)通信具有以下特點：
1）多點對多點傳輸數(shù)據(jù)。如果采用面向連接的方式進行通信，則需要每個模塊都各自維護到其它模塊的多個連接，處理起來很不方便，并且不利于擴充模塊。因此適合無連接的通信；
2）模塊間的數(shù)據(jù)通信具有突發(fā)性，通信數(shù)據(jù)量不規(guī)則、不連續(xù)。比較適合采用報文轉(zhuǎn)發(fā)方式傳輸；
3）通信目的計算機的IP地址可能改變，需要可配置；
4）模塊的數(shù)量可能擴充，也就是說，在同一臺計算機上運行的不同模塊的通信節(jié)點可能有多個，需要可配置；
5）模塊間傳輸數(shù)據(jù)必須保證通信的可靠性和數(shù)據(jù)的正確性；
6）某些通信要求實時性，通信異常導致陳舊數(shù)據(jù)必須清除。
3方案設(shè)計
根據(jù)第2節(jié)的影響因素分析，了解到通信方案需要解決四個問題，即通信接口問題、實時性可靠性均衡問題、IP端口可配置問題。首先，解決通信接口問題，需要將系統(tǒng)的數(shù)據(jù)通信工作獨立出來，與原本系統(tǒng)的其他應(yīng)用隔離開。因此，引入這樣兩個概念――通信層進程和應(yīng)用層進程。通信層進程負責為應(yīng)用層提供通信服務(wù)和其他輔助服務(wù)，如通信日志記錄、通信狀態(tài)監(jiān)控等；應(yīng)用層進程即原本系統(tǒng)各模塊運行的應(yīng)用進程，兩者間數(shù)據(jù)通信靠本機進程間通信維系?；诖_保實時性和大數(shù)據(jù)量的通信要求，本機進程間通信選取的方法是共享內(nèi)存，然后分別為通信層和應(yīng)用層提供讀寫共享內(nèi)存的接口，即使用DLL（動態(tài)鏈接庫）的方式分別加載到通信層程序和應(yīng)用層程序中。其次，解決實時性可靠性均衡問題，從多點通信和實時性的考慮出發(fā)，決定了選取無連接且傳輸更高效的UDP協(xié)議。然而，UDP協(xié)議不能保證可靠性，于是想到了對UDP協(xié)議進行二次封裝，形成一種兼顧通信的可靠性與實時性的新協(xié)議――RUDP協(xié)議。最后，采用通信層進程讀取.ini配置文件的配置信息的方法來解決IP端口可配置問題。
3.1 本機進程間通信
本機應(yīng)用層與通信層之間的進程間通信需要借助共享內(nèi)存技術(shù)、動態(tài)鏈接庫技術(shù)來實現(xiàn)。
共享內(nèi)存技術(shù)是通過內(nèi)存映射文件的方式來實現(xiàn)的。內(nèi)存映射文件是文件內(nèi)容到進程虛擬地址空間的復制。文件的內(nèi)容的拷貝稱為文件映像，而操作系統(tǒng)用來維持該拷貝的內(nèi)部結(jié)構(gòu)稱為文件映射對象。另一個進程通過使用第一個進程的文件映射對象建立映像，可以在它自己的虛擬地址空間建立完全一樣的文件映像，這樣就達到了進程間共享數(shù)據(jù)的目的。
設(shè)計方案將共享內(nèi)存分為兩種。一種發(fā)送報文時使用，應(yīng)用層進程向此共享內(nèi)存內(nèi)寫入報文，通信層進程分配線程采用輪循或接收消息通知的方式讀取共享內(nèi)存中的待發(fā)送報文，并通過套接字將其發(fā)送到目的計算機的通信層進程。這種共享內(nèi)存可稱之為發(fā)送結(jié)點共享內(nèi)存。另一種與此相反，接收報文時使用，通信層進程接收到報文后，根據(jù)報文首部判斷與之對應(yīng)的目的應(yīng)用層，并將報文寫入對應(yīng)的共享內(nèi)存，應(yīng)用層進程再讀出并解封裝報文。根據(jù)報文發(fā)送目的地址與源地址，可為每個源地址與目的地址分配對應(yīng)的共享內(nèi)存。每一塊共享內(nèi)存，有一個或幾個寫入線程，一個讀出線程與其相對應(yīng)。
動態(tài)鏈接庫（DLL）技術(shù)用來提供讀、寫、清空共享內(nèi)存的接口。在DLL完成相應(yīng)共享內(nèi)存的初始化工作后，發(fā)送接收雙方進程通過調(diào)用該DLL中相應(yīng)的寫入讀取共享內(nèi)存的函數(shù)訪問共享內(nèi)存，從而實現(xiàn)雙方的通信。雙方進程啟動后，用內(nèi)存映射文件的方式把一塊命名共享內(nèi)存映射到DLL附加的各個進程地址空間。
共享內(nèi)存的實現(xiàn)方式設(shè)計如圖1所示。
3.2 UDP協(xié)議二次封裝
RUDP就是在原TCP/IP協(xié)議的傳輸層的UDP協(xié)議和應(yīng)用層之間加入了一層為保證可靠數(shù)據(jù)傳送而實現(xiàn)的RUDP軟件模塊而形成的一個五層體系結(jié)構(gòu)，即在原有TCP/IP模型的應(yīng)用層和傳輸層之間加入一個定制的通信層（RUDP層），這樣就可以利用UDP協(xié)議實現(xiàn)一種基于消息的面向連接的可靠數(shù)據(jù)傳遞機制。
為了保證數(shù)據(jù)傳輸?shù)目煽啃?，可以借鑒TCP的三次握手原理，對UDP進行二次封裝，形成了RUDP傳輸機制。報文發(fā)送方對傳輸?shù)目煽啃院蛯崟r性要求通過應(yīng)用層與通信層的接口DLL，以出口函數(shù)的參數(shù)形式傳遞，然后再將這些信息封裝到原報文首部。通信層中解封裝報文首部，并根據(jù)這些信息靈活地選擇通信方式用以提高傳輸效率和保證可靠。
3.3配置文件
.ini配置文件用來靈活配置系統(tǒng)中某臺計算機需要通信的節(jié)點個數(shù)、通信目的地址、對端接收端口和本機綁定端口。.ini的讀寫通過調(diào)用api函數(shù)GetPrivateProfileInt()；GetPrivateProfileString()和WritePrivateProfileString()來實現(xiàn)。
4測試驗證
根據(jù)通信方案的設(shè)計，我們已經(jīng)編碼實現(xiàn)了一套通信中間件，包含單獨的通信層程序、配套動態(tài)鏈接庫通信接口及.ini配置文件，并在100Mbps傳輸速率的局域網(wǎng)中進行了一對一、多對一、多對多的測試驗證，得到測試結(jié)果如下表：
5結(jié)論
文中論述的通信方案確保了整個仿真系統(tǒng)可以高頻度大數(shù)據(jù)量地進行通信，實現(xiàn)了上層工作站、中層服務(wù)器與下層管理計算機之間的數(shù)據(jù)交互要求。在保證數(shù)據(jù)傳輸可靠性的的前提下，盡可能的滿足了數(shù)據(jù)傳輸?shù)膶崟r性。通信層完全獨立于需要通信的應(yīng)用層，通信接口良好，可以做到靈活配置，極大地方便了應(yīng)用層的調(diào)用，為今后整個仿真系統(tǒng)的擴展，通信需求的增加提供了良好保證。完善后的通信方案不僅適用于本仿真系統(tǒng)，還可以應(yīng)用于類似需求的局域網(wǎng)多點通信中。
參考文獻
[1]施煒，李崢，秦穎編著.Windows Sockets 規(guī)范及應(yīng)用-Windows網(wǎng)絡(luò)編程接口.
[2]周偉明.多核計算與程序設(shè)計.華中科技大學出版社，2009.
[3]汪翔，袁輝編著.Visual C++實踐與提高.網(wǎng)絡(luò)編程篇.中國鐵道出版社，2001.
[4]郎銳，孫方編著.Visual C++網(wǎng)絡(luò)通信程序開發(fā)基礎(chǔ)及實例解析.2版.北京：機械工業(yè)出版社，2006.
[5]電腦編程技巧與維護雜志社編著.Visual C++編程技巧典型案例解析網(wǎng)絡(luò)與通信及計算機安全與維護篇.北京：中國電力出版社，2005.
[6]劉化君編著.網(wǎng)絡(luò)編程與計算技術(shù).北京：機械工業(yè)出版社，2009.
[7]梁庚，白焰.Windows下進程間通信方式探討.微型電腦應(yīng)用，2006，22(12).
[8]馬魁濤，蔡穎，郭寶峰.Win32進程間信息共享的實現(xiàn)方法研究.
udp協(xié)議篇5
關(guān)鍵詞：IPSec；NAT；IKE；VPN；UDP封裝
中圖分類號：TP393文獻標識碼：A文章編號：1009-3044(2008)33-1360-03
Research on Coordination Between IPSec and NAT
ZHANG Ai-ke
(Departmet of Information Engineering, Liuzhou Vocational&Technical College,Liuzhou 545006,China)
Abstract: Network Address Translation (NAT) and IP security protocol (IPSec) are outstanding technologies that are widely used in network. At present, because IPSec and NAT are incompatible, the technologies can not co-exist in network at the same time. This paper engages in the research upon the coordination between IPSec and NAT. points out the application scope of NAT-T so as to guide the optimum IPSec VPN implementation.
Key words: IPSec;NAT;IKE;VPN;UDP encapsulation
1 引言
IPSec與NAT是用來解決IPv4中網(wǎng)絡(luò)安全與IP地址短缺問題的兩項技術(shù)。IPSec是Internet工程任務(wù)組（IETF）制定的一系列安全標準[1]，已被確定為IPv6的必需組成部分，是下一代網(wǎng)絡(luò)的安全標準，它可以較好地解決目前Internet上面臨的安全威脅，有效地保證數(shù)據(jù)的安全傳輸。隨著Internet的不斷發(fā)展，采用IPSec技術(shù)實現(xiàn)利用互聯(lián)網(wǎng)建立VPN網(wǎng)絡(luò)，越來越被眾多大中型企業(yè)所青睞，IPSec已逐漸成為構(gòu)建VPN的主流技術(shù)。網(wǎng)絡(luò)地址轉(zhuǎn)換（NAT）技術(shù)[2] 在內(nèi)部網(wǎng)絡(luò)中使用內(nèi)部私有IP地址，通過NAT將每個從內(nèi)部網(wǎng)絡(luò)發(fā)出的數(shù)據(jù)包的私有地址翻譯成合法的公用IP地址在Internet上使用，支持多臺主機共享全局IP地址，常見于接入設(shè)備和防火墻中，能很好地解決IPv4網(wǎng)絡(luò)地址枯竭的問題，同時具有屏蔽內(nèi)部網(wǎng)絡(luò)的作用。
然而，在實際應(yīng)用中，IPSec技術(shù)和NAT技術(shù)存在嚴重的不兼容性，當IPSec數(shù)據(jù)流穿越NAT設(shè)備時，兩者無法協(xié)同工作，已被廣泛使用的NAT設(shè)備制約著基于IPSec技術(shù)的VPN的發(fā)展。因此，IPSec和NAT兼容性方面的問題已成為當前網(wǎng)絡(luò)安全領(lǐng)域的研究熱點，尋求基于IPSec技術(shù)的VPN和現(xiàn)有的NAT設(shè)備和平共處，實現(xiàn)NAT透明穿越的解決方案已成為迫在眉睫的任務(wù)。
2 問題描述
由于IPSec對數(shù)據(jù)包進行保護，對數(shù)據(jù)包的改動會導致驗證或解密過程的失敗。IPSec與NAT的兼容性沖突是多方面的，其中主要是由于IPSec數(shù)據(jù)包在穿越NAT時無法進行正確轉(zhuǎn)換造成的。IPSec與NAT的不兼容性問題主要有以下幾個方面[3]：
1) IPSec AH和NAT：AH利用消息摘要算法對整個IP數(shù)據(jù)包產(chǎn)生一個散列值，該散列值的作用范圍是整個IP包，包括源IP地址和目的IP地址，接收方利用該散列值認證收到的IP數(shù)據(jù)包。如果在發(fā)送過程中原始IP包的任何字段發(fā)生變化，都將會導致接收方的認證失敗，接收方將丟棄該包。但NAT會對外出包的源地址和進入包的目的地址進行修改，AH認為IP包被非法修改，從而導致認證失效。ESP的完整性檢查不包括IP頭（傳輸模式），或者檢查的是不為NAT所修改的內(nèi)嵌IP協(xié)議頭（隧道模式），因此在ESP中不存在這樣的問題。
2) 校驗和與NAT：TCP和UDP在計算校驗和時使用了偽頭部，因而校驗和與IP源和目的地址有依賴關(guān)系。因此，當NAT設(shè)備改變IP地址后需要重新計算并修改TCP/UDP校驗和。當應(yīng)用了ESP傳輸模式的IP包經(jīng)過NAT設(shè)備時，由于TCP/UDP校驗和處于加密負載之中，該值在在修改了外層IP包頭后無法被NAT進行更新，這樣，雖然IPSec不會丟棄這個包，但是當它被送往上層協(xié)議處理，在進行校驗和校驗時會出錯，這個包還是會被丟棄。ESP隧道模式可以和靜態(tài)或動態(tài)NAT相兼容，因為TCP/UDP校驗和只與內(nèi)層“原始”IP包頭有關(guān)，對于外層IP包頭的的修改并不對其造成影響。然而，在NAPT存在的情況下，AH和ESP都無法通過NAPT，NAPT需要TCP/UDP端口來匹配出入信包，上層端口信息對于NAT網(wǎng)關(guān)是不可知的，所以NAT網(wǎng)關(guān)無法完成多個私網(wǎng)地址映射到一個公網(wǎng)地址的變換。
3) IKE地址標識符和NAT：在IKE協(xié)商中，通信雙方使用IP地址作為身份標識符，而NAT設(shè)備對IP地址的修改會引起IP頭中的地址和標識符不符，IKE會將這樣的包丟掉。
4) IKE固定的目標端口和NAPT：IKE協(xié)商時的UDP通信端口號一般固定是500，而當NAPT后面的多方主機向同一響應(yīng)者發(fā)起IKE SA時，NAPT需要通過不同的端口號區(qū)分不同的連接，因此，響應(yīng)者必須能夠接受非500UDP端口的IKE流量。
5) 重疊的SPD項和NAT：在IKE協(xié)商的第二階段中，NAT后的多個主機和相同響應(yīng)者協(xié)商SPD時會出現(xiàn)重疊，這樣，響應(yīng)者可能在錯誤的IPSec SA下發(fā)送數(shù)據(jù)包。
6) IPSec SPI選擇符和NAT：IPSec ESP流量受加密保護，對NAT是透明的，NAT必須使用IP頭和IPSec頭來多路分解到來的IPSec信包，目的IP地址、安全協(xié)議（AH/ESP）、和SPI共同惟一標識一個安全聯(lián)盟來達到這個目的。由于SA是單向的，外出和進入包的SPI選取是獨立的，因此，僅通過監(jiān)測外出的流量，NAT無法決定哪個進入的SPI和哪個目標主機相對應(yīng)。
7) 內(nèi)嵌IP地址和NAT：當內(nèi)嵌IP地址時，由于載荷受到完整性保護，IPSec包中的任何IP地址不能被NAT轉(zhuǎn)換。內(nèi)嵌IP地址的協(xié)議包括FTP、IRC、SNMP、LPAP、H.232、SIP和許多游戲協(xié)議。
除上述外，有些NAT的具體實現(xiàn)也存在不利于IPSec穿越的特點，例如：某些NAT供應(yīng)商的NAPT不能處理非UDP/TCP報文，拒絕通過ESP、AH報文；有些幫助解決兼容性問題的方法會引起新的不兼容性，如對端口500的特殊處理、對ISAKMP有效載荷進行解析及ISAKMP頭部檢查等。
3 協(xié)同工作的方法
IPSec和NAT的兼容性方案的目的是擴大IPSec的適用范圍。根據(jù)前面分析的IPSec與NAT之間存在的兼容性問題，以及評估一個解決方案的可配置性、可擴展性、多模式支持能力、與防火墻的兼容性、遠程通信能力、互操作性和安全性等原則[4]，下面來探討一些方法來解決IPSec和NAT協(xié)同工作的問題。
3.1 RSIP方法
RSIP是指在不同地址域通信的主機自己能處理跨越不同地址域的地址變換問題。它的工作機制[5]是：當RSIP客戶機要聯(lián)系互聯(lián)網(wǎng)上主機的時候，它查詢RSIP服務(wù)器以便獲得一個端口號和公網(wǎng)IP地址。接著客戶機通過隧道將包發(fā)往RSIP服務(wù)器，RSIP服務(wù)器將隧道頭剝掉，然后將包發(fā)向互聯(lián)網(wǎng)。對于到達的包，RSIP服務(wù)器基于端口號查找客戶機IP地址，加入隧道頭，然后將它們發(fā)往RSIP客戶機。
RSIP網(wǎng)關(guān)是跨越在多個編址域的多宿主設(shè)備，允許主機直接參與到多個編址域中，并不對地址進行翻譯，這樣盡管主機需要知道RSIP網(wǎng)關(guān)，但是卻沒有破壞Internet端到端的通信，應(yīng)用RSIP不需要修改源到目的地的IP載荷流，也就避免了對AH、ESP等協(xié)議的損傷。
RSIP技術(shù)的完全實現(xiàn)需要用新的RSIP網(wǎng)關(guān)代替現(xiàn)有的NAT路由設(shè)備，同時涉及對客戶機的修改、服務(wù)器的重新部署等問題，因此實施費用相對較大，部署時間較長，降低了該方案的可行性。
3.2 “6to4”方法
這種方法的基本原理[6]是：各個局部網(wǎng)絡(luò)運行在IPv6上，在IPv6網(wǎng)絡(luò)邊界安裝NAT，NAT給主機提供IPv6地址前綴，這個地址前綴是NAT設(shè)備的IPv4 IP地址，當IPv6的數(shù)據(jù)報到達NAT時，NAT提取IPv6的地址前綴作為IPv6數(shù)據(jù)報的IPv4隧道地址，NAT把IPv6數(shù)據(jù)包封裝在IPv4數(shù)據(jù)包中發(fā)送出去；在響應(yīng)方，相應(yīng)的NAT作IPv4隧道的解封，解封后的數(shù)據(jù)包在局部網(wǎng)絡(luò)中用IPv6協(xié)議進行路由。在各個VPN保護的子網(wǎng)中是基于IPv6協(xié)議通信的。
這種方法很好地考慮了將來整個網(wǎng)絡(luò)升級到IPv6的情況，同時它需要的支持也很少。
但這種方式要求對NAT進行修改，現(xiàn)在NAT的分布已非常廣泛，而且很多NAT設(shè)備部署在公司、機構(gòu)無法控制的地方，例如：ISP部署NAT在它的接入服務(wù)器上。因此，實施這種方式的費用較高，短期內(nèi)難以實現(xiàn)。
3.3 專用NAT方法
其基本思想是：在VPN網(wǎng)關(guān)接收到數(shù)據(jù)包時作一次該網(wǎng)關(guān)專用的NAT，將通信鏈路中作了NAT的數(shù)據(jù)包根據(jù)策略配置恢復沒有NAT時的IP地址或端口，當數(shù)據(jù)包通過網(wǎng)關(guān)到達目的地時，與通信鏈路中沒有NAT時的數(shù)據(jù)包一樣。通過這種方式來解決IPSec與NAT兼容性問題的關(guān)鍵是：在雙方初始通信時確定NAT的存在，把經(jīng)過NAT的數(shù)據(jù)包和系統(tǒng)策略配置中的連接相聯(lián)系起來，為通信雙方的后續(xù)通信建立地址、策略綁定，維持這個連接的狀態(tài)，后續(xù)的通信根據(jù)連接狀態(tài)作NAT。
這種處理方式將內(nèi)部網(wǎng)絡(luò)的拓撲結(jié)構(gòu)暴露給了通信對方的網(wǎng)關(guān)，通信鏈路中的竊聽者也能得到這部分信息，并且每個客戶端都必須安裝有這個解決方案的實現(xiàn)。專用NAT沒有正式文檔描述，在已有的幾個產(chǎn)品中可以見到，如e-Border Solution provided by Permeo Technologies，Inc。目前沒有提供也沒有實現(xiàn)這種方案的系統(tǒng)之間的兼容性。
3.4 UDP封裝方法
UDP封裝法[7]是IETF提出的一種用于IPSec穿越NAT的解決方案，基本思想是：由發(fā)送主機在發(fā)送前將IPSec數(shù)據(jù)包封裝在UDP中，到達接收方后再去掉外面的IP頭以及UDP封裝，從而使其中的IPSec數(shù)據(jù)包不受影響。ESP協(xié)議在傳輸模式和隧道模式下UDP封裝格式分別如圖1、圖2所示。
圖1 ESP傳輸模式UDP封裝數(shù)據(jù)格式變化圖
圖2 ESP隧道模式UDP封裝數(shù)據(jù)格式變化圖
UDP封裝法的實現(xiàn)需要對IKE協(xié)商進行改進來配合。
1) IKE協(xié)商第一階段
在這一階段中需要完成兩種探測：探測對方是否支持NAT穿越（NAT-T）；探測在通信路徑中是否存在NAT設(shè)備。在IKE第一階段的前兩條交換消息中，發(fā)送“廠商ID載荷”，如果對方支持NAT，那么它就能識別此載荷，因為它詳細描述了對NAT穿越的支持。然后在主模式的第三個和第四個交換消息或者野蠻模式的第二個和第三個交換消息中，增加載荷NAT-D（NAT-Discovery），載荷的值是源或者目的地址和端口號的HASH值，計算如下：
HASH=HASH（CK-I│CK-R│IP│Port）
其中CK-I，CK-R分別是發(fā)送方和接收方的Cookie值。當對方收到NAT-D載荷后，計算地址和端口的HASH值，如果與收到的相同，則表示它們之間沒有NAT，否則表明鏈路中有NAT設(shè)備對它做了改變。如果發(fā)送者不能確定自己的IP地址，它可以在報文中包含多個本地IP地址的HASH值，僅當所有的HASH值均不匹配時，才表明有NA設(shè)備存在。
一些NAT設(shè)備不改變源端口500，即使NAT后面有多個客戶機。這些NAT設(shè)備通過Cookie值而不是端口來完成與后面多個客戶機的映射，這樣，IKE很難發(fā)現(xiàn)NAT設(shè)備的兼容性能力。最好的方法是發(fā)現(xiàn)存在NAT設(shè)備后，把IKE傳輸從端口500上移走。一般在NAT設(shè)備被探測到后，發(fā)起者必須立刻將UDP的源端口和目的端口都設(shè)置為4500。這樣會出現(xiàn)一個問題：IKE協(xié)商數(shù)據(jù)包（UDP數(shù)據(jù)包）和協(xié)商完成后的UDP封裝ESP數(shù)據(jù)包使用相同的端口4500進行發(fā)送，為了區(qū)分出這兩種數(shù)據(jù)包，在IKE數(shù)據(jù)包的UDP頭和IKE頭之間添加四字節(jié)的Non-ESP標志，與UDP封裝的ESP包中的SPI域?qū)R，且值為全零。封裝后的IKE包和ESP包的格式[8]如圖3所示。
圖3UDP封裝后IKE包和ESP包的區(qū)別
2) IKE協(xié)商第二階段
如果在第一階段發(fā)現(xiàn)有NAT設(shè)備存在，IKE的第二階段協(xié)商SA時就作相應(yīng)的變化：添加兩種新的模式：UDP封裝隧道模式和UDP封裝傳輸模式；增加NAT-OA以發(fā)送發(fā)起者的原始IP地址，以修正因NAT變換后的TCP/UDP校驗和；位于NAT后面的IPSec發(fā)起方定期發(fā)送保持激活報文（keep alive），用以保持所建立的NAT映射不變。
該方案不需要對IKE或IPSec協(xié)議本身做任何的改動，只需要對IKE的實現(xiàn)做一些小的改進，該方法只依賴于NAT對UDP的支持，所以可以與絕大多數(shù)的NAT設(shè)備一起協(xié)同工作，具有簡單且易于實現(xiàn)的優(yōu)點，在總體上對NAT穿越問題有了較好的解決。但是，該方案的缺點也很明顯：不支持AH協(xié)議，增加了載荷長度，延長了IKE協(xié)商SA的時間，無法實現(xiàn)NAT后多主機發(fā)起通信，泄漏了內(nèi)網(wǎng)地址信息等。盡管如此，IETF提出的UDP封裝法及在它基礎(chǔ)上進行的各種改進，仍然是目前解決IPSec與NAT兼容性問題的主流技術(shù)。
3.5 TCP封裝方法
使用UDP協(xié)議的好處在于傳輸數(shù)據(jù)比較快，UDP協(xié)議在傳輸小數(shù)據(jù)量時確實比TCP協(xié)議有更好的效率。但是，當需要傳輸?shù)臄?shù)據(jù)量比較大（如使用數(shù)字證書進行身份認證和密鑰協(xié)商）時，UDP協(xié)議數(shù)據(jù)容易失序和丟失；在一個噪音比較大，數(shù)據(jù)失真比較多，容易受干擾的網(wǎng)絡(luò)環(huán)境（如無線網(wǎng)絡(luò)）中，往往造成數(shù)據(jù)的大量失真。出現(xiàn)這些情況時，需要上層協(xié)議對UDP數(shù)據(jù)包進行重新排序或重傳等操作，由此造成的效率損失往往比較大，在此我們可以考慮使用TCP協(xié)議進行密鑰協(xié)商。TCP協(xié)議能夠很好地處理數(shù)據(jù)報的失序和丟失問題，在大數(shù)據(jù)量傳輸時也有很好的表現(xiàn)。TCP協(xié)議在建立過程和拆除過程中的數(shù)據(jù)交換所造成的效率損失并不比UDP協(xié)議處理時的損失大。
在實際的應(yīng)用環(huán)境中，使用UDP封裝會遇到以下的復雜情況：UDP數(shù)據(jù)屬于上層數(shù)據(jù)，如果長度比較大，IP層會對此數(shù)據(jù)進行分片，先由IPSec協(xié)議對此分片數(shù)據(jù)進行封裝，再由UDP協(xié)議進行二次封裝以穿越NAT；到達目的地后拆除UDP的二次封裝，需要再由IP層對分片數(shù)據(jù)進行重組。假如其中UDP二次封裝的一個數(shù)據(jù)報丟失，那么整個UDP數(shù)據(jù)報都需要重新發(fā)送而不是只發(fā)送丟失的數(shù)據(jù)分片。這將造成整個通信效率明顯下降。在此我們可以考慮使用TCP協(xié)議對IPSec數(shù)據(jù)包進行二次封裝。TCP協(xié)議不會造成數(shù)據(jù)的失序和丟失，TCP協(xié)議會自動重新發(fā)送丟失的數(shù)據(jù)報而不是全部業(yè)務(wù)數(shù)據(jù)重新發(fā)送。此時使用TCP不會造成明顯的效率降低，而是更好地提供了數(shù)據(jù)的傳輸服務(wù)。
以上分析的雖然是復雜的情形，但VPN通信是面向廣域網(wǎng)的安全傳輸需求，它相比局域網(wǎng)環(huán)境中的通信要復雜得多，在實際應(yīng)用中各種情況都可能出現(xiàn)，所以用TCP代替UDP對IPSec數(shù)據(jù)包進行封裝以穿越NAT設(shè)備的考慮是具有現(xiàn)實意義的。
4 結(jié)束語
基于IPSec的VPN技術(shù)和NAT技術(shù)都是充滿前途和廣泛被使用的網(wǎng)絡(luò)技術(shù)，解決IPSec和NAT的協(xié)同工作問題，對于部署VPN具有重要的意義。該文在詳細分析了影響IPSec和NAT無法兼容的原因后，提出了實現(xiàn)NAT穿越幾種方法，其中詳細介紹了比較適用于目前網(wǎng)絡(luò)環(huán)境的UDP封裝法，并提出了用TCP封裝IPSec數(shù)據(jù)包的設(shè)想，下一步的研究工作就是在此基礎(chǔ)上進一步深入加以完善。
參考文獻：
[1] Naganand Doraswamy.IPSec新一代因特網(wǎng)安全標準[M].北京:機械工業(yè)出版社,1998.
[2] RFC-1631-1994.The IP Network Address Translator (NAT) [S].
[3] 譚興烈,張世雄.IPSec和NAT協(xié)同工作技術(shù)研究[J].計算機工程與應(yīng)用,2003(12):I64-165.
[4] 李孝展,潘金貴.IPSec與NAT兼容性問題及其解決方案剖析[J].計算機應(yīng)用與軟件,2007,24(2):161-163.
[5] RFC-3103-2001.M.Borella, D.Grabelsky ,J Lo,K.Taniguchi. Ream Specific IP:Protocol Specification( RSIP)[S].
[6] RFC-3056-2001.B.Carpente and K.Moore.Connection of IPv6 Domains via IPv4 Clouds[S].
[7] RFC-3984-2005. A. Huttunen, W. Dixon, V. Volpe. UDPEncapsulation of IPsec Packets[S].
udp協(xié)議篇6
關(guān)鍵詞： TCP/IP；TCP協(xié)議； UDP協(xié)議；Winsock；遠程監(jiān)測
中圖分類號：TP393 文獻標識碼：A 文章編號：1009-3044（2013）04-0731-06
Design of TCP and UDP Communication Test Software
TU Jin-long
（Nanjing Communications Institute of Technology， Nanjing 211188， China）
Abstract： TCP and UDP are two protocols of TCP/IP transmission layer protocol. They use IP routing function to send packets to destinations， thus provide network services for applications and application layer protocols. TCP and UDP both have their advantages and disadvantages， the mai n difference between them lies in the connection state. Applications choose accord to the actual usage. Winsock can be used to write client and server applications without the need of knowing details of the TCP/IP. By setting Winsock attributes and call its control methods， connection to remote computers and two-way data exchange can be easily achieved.
Key words： TCP/IP； TCP protocol； UDP protocol； Winsock； remote monitoring
根據(jù)國家有關(guān)標準，各地應(yīng)加強對客運車輛燃料消耗量檢測和監(jiān)督管理，加快淘汰、更新高耗能的老舊營運車輛。但迄今為止，我國客運行業(yè)的能耗統(tǒng)計一直采用手工填寫統(tǒng)計報表的方式，不僅投入的人力物力大、數(shù)據(jù)誤差大，而且不能實時了解能耗情況。為此，需要研發(fā)一種客車能耗遠程監(jiān)測系統(tǒng)，以便實時快速地采集客車運營過程中的有關(guān)信息，實現(xiàn)全自動的客車能耗數(shù)據(jù)分析、處理、評估，從而改變現(xiàn)行的由人工按月或年度填寫報表的統(tǒng)計方式，提高工作效率及數(shù)據(jù)的準確性，為管理部門對高能耗高污染車輛實施強制淘汰或報廢提供數(shù)據(jù)支持。
隨著計算機技術(shù)及網(wǎng)絡(luò)技術(shù)的不斷發(fā)展，人們的生活和工作越來越離不開網(wǎng)絡(luò)，尤其是網(wǎng)絡(luò)遠程控制技術(shù)已經(jīng)廣泛地應(yīng)用于網(wǎng)絡(luò)自動化管理、實時監(jiān)控等方面。針對移動運行的客車，要實時獲取有關(guān)數(shù)據(jù)，就需要憑借無線網(wǎng)絡(luò)將采集到的數(shù)據(jù)傳到監(jiān)控中心。在眾多的網(wǎng)絡(luò)通信中，以TCP/IP協(xié)議最為流行，為了測試遠程無線通信在具有防火墻的系統(tǒng)中的有效性，針對應(yīng)用的特殊性，以及為了順利進行軟硬件的配接，需要先編寫一個測試通信鏈路的TCP和UDP通信測試軟件。
TCP和UDP是TCP/IP體系結(jié)構(gòu)中的兩個傳輸層協(xié)議，它們使用IP路由功能把數(shù)據(jù)包發(fā)送到目的地，從而為應(yīng)用程序及應(yīng)用層協(xié)議提供網(wǎng)絡(luò)服務(wù)。TCP提供的是面向連接的可靠的端到端傳送服務(wù)，它可以在低層不可靠的情況下（如出現(xiàn)分組傳輸?shù)膩G失、亂序等）提供可靠的傳輸機制。而UDP提供的是無連接的、不可靠的傳輸服務(wù)，在數(shù)據(jù)傳輸之前，不需要建立連接，而且收方收到UDP數(shù)據(jù)報文之后，也不需要給出任何應(yīng)答信息。顯然，UDP減少了很多的為保證可靠傳輸而附加的額外開銷，因而它的效率高[1]。因此，TCP與UDP各有其優(yōu)缺點，要根據(jù)實際應(yīng)用進行選擇。
1 TCP和UDP測試軟件的設(shè)計
使用TCP和UDP通信的方法有多種，在VB開發(fā)平臺上使用Winsock控件來設(shè)計軟件可以說是最方便的。Winsock即Windows Sockets規(guī)范的簡稱，是目前最流行的網(wǎng)絡(luò)通信應(yīng)用程序接口之一。Socket通常也稱作“套接字”，用于描述IP地址和端口，是一個通信鏈的句柄。應(yīng)用程序通常通過“套接字”向網(wǎng)絡(luò)發(fā)出請求或者應(yīng)答網(wǎng)絡(luò)請求。
Winsock控件對用戶是不可見的，但它提供了訪問TCP/IP網(wǎng)絡(luò)的捷徑，使用它可以通過UDP協(xié)議或TCP協(xié)議方便地連接到遠程的機器并進行數(shù)據(jù)交換。用Winsock控件編寫客戶和服務(wù)器應(yīng)用程序，不需要了解TCP/IP或調(diào)用底層Winsock API的具體細節(jié)。通過設(shè)置Winsock控件的屬性和調(diào)用該控件的方法，可以很容易地連接到遠程計算機并進行雙向的數(shù)據(jù)交換。
使用WinSock控件時，首先要確定的是使用TCP還是UDP協(xié)議，它們之間主要的區(qū)別在于連接狀態(tài)。
1.1 TCP測試軟件設(shè)計
TCP協(xié)議是面向連接的協(xié)議，在數(shù)據(jù)傳輸前就建立好了點到點的連接。TCP網(wǎng)絡(luò)程序工作原理如圖1所示[2]。
圖1 TCP網(wǎng)絡(luò)程序工作原理
基于 TCP/IP 協(xié)議網(wǎng)絡(luò)通信主要模式就是客戶機/服務(wù)器模式（Client/Server 模式，簡稱 C/S），即客戶端提出請求，服務(wù)器在監(jiān)聽時接收到請求后就提供請求服務(wù)。遠程控制是基于 C/S 模式來實現(xiàn)的，所以程序分為服務(wù)器和客戶端程序?？蛻舳撕头?wù)器端連接成功后，通過信息交換取得相應(yīng)的服務(wù)。因此，在進行編程時，服務(wù)器端程序應(yīng)設(shè)置Winsock控件的LocalPort屬性和調(diào)用 Listen 方法來監(jiān)聽，客戶機端程序則要設(shè)置 Winsock 控件的 RemoteHost 和 RemotePort 屬性、調(diào)用 Connect 方法請求連接[3]。一旦建立了連接，兩臺計算機之間就可以發(fā)送和接受數(shù)據(jù)了。要發(fā)送數(shù)據(jù)，調(diào)用SendData方法。當接受數(shù)據(jù)時，產(chǎn)生DataArrival事件。在DataArrival事件中調(diào)用GetData方法來接收數(shù)據(jù)。
在VB6開發(fā)平臺上可以方便地使用Winsock控件來設(shè)計網(wǎng)絡(luò)通信軟件，為了測試的方便，將客戶端和服務(wù)器端的軟件設(shè)計在同一軟件中，通過標簽來選擇是客戶端還是服務(wù)器端，或是UDP測試，也可以在同一臺電腦中運行軟件完成測試。在設(shè)計階段，添加好必要的窗體和按鈕、文本框并設(shè)置所需的名稱、屬性后，在窗體中放置Winsock控件，在屬性窗口里的協(xié)議，選擇sckTCPProtocol，也可以在代碼里配置協(xié)議，例如：
Winsock1.Protocol=sckTCPProtocol
1.1.1服務(wù)器端程序
為了能接受多個連接請求，需要創(chuàng)建新的控件實例，調(diào)用新的實例中的接受方法。下面是創(chuàng)建一個服務(wù)器端程序的主要內(nèi)容：
1）設(shè)置端口并偵聽（監(jiān)聽）。雙擊“開始偵聽”按鈕，在代碼中加入要設(shè)置的LocalPort，并開始監(jiān)聽，代碼如下：
Private Sub cmdListen_Click（）
If TCP_Server（0）.State sckClosed Then TCP_Server（0）.Close
TCP_Server（0）.LocalPort = txtLocalPort（2）.Text
TCP_Server（0）.Listen
End Sub
2）監(jiān)聽連接請求。監(jiān)聽方法在控件中被調(diào)用，每個連接請求到來時，代碼會測試看它的索引（Index）是否為0（監(jiān)聽控件的值），根據(jù)其值是否為0執(zhí)行不同的操作。代碼如下：
Private Sub TCP_Server_ConnectionRequest（Index As Integer， ByVal requestID As Long）
Dim i As Long
If Index = 0 Then '主Winsock——Winsock（0）發(fā)生消息
i = 1
If maxConnext > 0 Then
While i
i = i + 1
DoEvents
Wend
End If
If i
TCP_Server（i）.LocalPort = txtLocalPort（2）.Text
TCP_Server（i）.Accept requestID
nowconnext（i） = True 'Winsock（i）被占用
Else
If maxConnext > 50 Then
MsgBox "已經(jīng)達到最大用戶數(shù)！"， vbExclamation + vbOKOnly， "提示"
Exit Sub
End If
maxConnext = maxConnext + 1
Load TCP_Server（maxConnext）
TCP_Server（maxConnext）.LocalPort = txtLocalPort（2）.Text
TCP_Server（maxConnext）.Accept requestID
ReDim Preserve nowconnext（maxConnext + 1）
nowconnext（maxConnext） = True
ReDim Preserve saveServerData（maxConnext + 1）
ReDim Preserve saveServerIndex（maxConnext + 1）
i = maxConnext
End If
End If
End Sub
3）服務(wù)器端發(fā)送數(shù)據(jù)。若選中發(fā)送回車符，則在代碼中增加發(fā)送回車符，若選中發(fā)送換行符，則在代碼中增加發(fā)送換行符。若是廣播，則逐個發(fā)送，否則需要選擇發(fā)送目標。主要代碼如下：
Private Sub cmdSend3_Click（）
Dim i As Integer
Dim sendresult As Long
Dim sendsrc（） As Byte
Dim sendsrclen As Long
Dim sendmess（1 To 1024） As Byte
Dim outByte（） As Byte
If Me.ckHex（2）.Value = 1 Then '十六進制發(fā)送
sendsrclen = Len（txtSend（2）.Text） / 2 - 1
ReDim sendsrc（0 To sendsrclen）
For i = 0 To sendsrclen
sendsrc（i） = Val（"&H" & Mid（txtSend（0）.Text， i * 2 + 1， 2））
Next
Else
outByte = StrConv（txtSend（2）.Text， vbFromUnicode）
sendsrc = outByte
sendsrclen = UBound（outByte）
End If
If chkGB.Value = 1 Then
For i = 1 To maxConnext
If TCP_Server（i）.State = sckConnected Then
TCP_Server（i）.SendData sendsrc
End If
DoEvents
Next
Else
Dim findSerVer As Boolean
For i = 1 To maxConnext
If saveServerIndex（i） = Val（Combo1.Text） Then
findSerVer = True
Exit For
End If
Next
If i > 0 And findSerVer = True Then
If TCP_Server（i）.State = sckConnected Then
TCP_Server（i）.SendData sendsrc
End If
Else
MsgBox "請選擇發(fā)送目標！"， ， "提示："
End If
End If
End Sub
4）服務(wù)器端接收數(shù)據(jù)，數(shù)據(jù)到達后，先調(diào)用TCP_Server控件的getdata方法，將接收的數(shù)據(jù)以vbstring數(shù)據(jù)類型，存放在strdata變量之中，然后再加到txtReceive（2）控件之中。主要代碼如下：
Private Sub TCP_Server_dataarrival（Index As Integer， ByVal bytestotal As Long）
Dim strdata As String
TCP_Server（Index）.GetData strdata， vbString
txtReceive（2）.Text = txtReceive（2）.Text & Index & "：" & TCP_Server（Index）.RemoteHostIP & "：" & TCP_Server（Index）.RemotePort & "：" & strdata & vbCr
End Sub
以上是創(chuàng)建一個服務(wù)器端程序的主要內(nèi)容，為了方便使用，還可適當增加一些輔助的功能，運行后的服務(wù)器端界面如圖2所示。
圖2 TCP協(xié)議服務(wù)器端測試軟件運行界面
1.1.2 客戶端程序
1）設(shè)置遠程主機端口并連接。雙擊“建立連接”按鈕，在代碼中指定遠程主機的ip地址，并調(diào)用TCP_Client控件的connect方法，來初始化與主機的連接請求，代碼如下：
Private Sub cmdConnect_Click（）
On Error GoTo connectErr
If Tcp_Client.State sckClosed Then Tcp_Client.Close
Tcp_Client.RemoteHost = txtRemoteHost（1）.Text
Tcp_Client.RemotePort = txtRemotePort（1）.Text
Tcp_Client.Connect
TimerConnect.Enabled = True
Exit Sub
connectErr：
StatusBar1.Panels.Item（2）.Text = "未能成功連接。" & Err.Number
End Sub
2）客戶端發(fā)送數(shù)據(jù)。若選中發(fā)送回車符，則在代碼中增加發(fā)送回車符，若選中發(fā)送換行符，則在代碼中增加發(fā)送換行符。主要代碼如下：
Private Sub cmdSend2_Click（）
Dim i As Integer
Dim sendresult As Long
Dim sendsrc（） As Byte
Dim sendsrclen As Long
Dim sendmess（1 To 1024） As Byte
Dim outByte（） As Byte
On Error Resume Next
If Me.ckHex（1）.Value = 1 Then '十六進制發(fā)送
sendsrclen = Len（txtSend（1）.Text） / 2 - 1
ReDim sendsrc（0 To sendsrclen）
For i = 0 To sendsrclen
sendsrc（i） = Val（"&H" & Mid（txtSend（0）.Text， i * 2 + 1， 2））
Next
Else
outByte = StrConv（txtSend（1）.Text， vbFromUnicode）
sendsrc = outByte
sendsrclen = UBound（outByte）
End If
If chk13（1）.Value = 1 Then
sendsrclen = sendsrclen + 1
ReDim Preserve sendsrc（0 To sendsrclen）
sendsrc（sendsrclen） = 13
End If
If chk10（1）.Value = 1 Then
sendsrclen = sendsrclen + 1
ReDim Preserve sendsrc（0 To sendsrclen）
sendsrc（sendsrclen） = 10
End If
If Tcp_Client.State = sckConnected Then
Tcp_Client.SendData sendsrc
Else
MsgBox "請先建立連接！"， ， "提示："
End If
End Sub
3）客戶端接收數(shù)據(jù)，先調(diào)用TCP_Client控件的getdata方法，將接收的數(shù)據(jù)以vbstring數(shù)據(jù)類型存放strdata變量之中，然后將strdata變量的內(nèi)容，加到txtReceive（1）控件之中。主要代碼如下：
Private Sub TCP_Client_dataarrival（ByVal bytestotal As Long）
Dim strdata As String
Tcp_Client.GetData strdata， vbString
txtReceive（1）.Text = txtReceive（1）.Text & strdata
End Sub
本部分是創(chuàng)建一個客戶端程序的主要內(nèi)容，運行后的界面如圖3所示。
1.2 UDP測試軟件
UDP是無連接的協(xié)議。與TCP操作不同，計算機并不建立一個連接。并且，UDP應(yīng)用程序可以是用在客戶端，也可以用在服務(wù)器端。使用UDP協(xié)議，在兩個Winsock控制間進行數(shù)據(jù)的發(fā)送，在連接的兩端必須完成以下三步：
1）設(shè)置RemoteHost屬性；
2）設(shè)置RemotePort屬性；
3）申請Bind方法。
通過使用方法Bind，則可將該Winsock捆綁到一個本地端口，以便該Winsock使用該端口來進行類似TCP的“監(jiān)聽”功能，并防止其它應(yīng)用使用該端口。
使用UDP協(xié)議傳送數(shù)據(jù)，首先設(shè)置客戶計算機的LocalPort屬性。而作為服務(wù)器的計算機僅需要設(shè)置RemoteHost屬性為客戶計算機的IP地址或域名，并將其RemotePort屬性設(shè)置成客戶計算機上的LocalPort屬性。主要代碼如下：
WinsockUDP.RemoteHost = txtRemoteHost（0）.Text
WinsockUDP.RemotePort = txtRemotePort（0）.Text
WinsockUDP.LocalPort = txtLocalPort（0）.Text
WinsockUDP.Bind txtLocalPort（0）
然后就可通過SendData方法來開始信息發(fā)送，客戶計算機則可在其DataArrial事件中使用方法GetData來獲取發(fā)送的信息，發(fā)送和接收數(shù)據(jù)的代碼與TCP通信的代碼類似。UDP測試程序運行后的界面如圖4所示。
圖4 UDP協(xié)議測試軟件運行界面
2 結(jié)束語
TCP和UDP是TCP/IP體系結(jié)構(gòu)中的兩個傳輸層協(xié)議，它們使用IP路由功能把數(shù)據(jù)包發(fā)送到目的地，從而為應(yīng)用程序及應(yīng)用層
協(xié)議提供網(wǎng)絡(luò)服務(wù)。TCP提供的是面向連接的可靠的端到端傳送服務(wù)，而UDP提供的是無連接的傳輸服務(wù)，在數(shù)據(jù)傳輸之前，不需要建立連接，因而它的效率高。TCP與UDP各有其優(yōu)缺點，它們之間主要的區(qū)別在于連接狀態(tài)，應(yīng)用時要根據(jù)實際應(yīng)用進行選擇。
使用TCP和UDP通信的方法有多種，在VB開發(fā)平臺上使用Winsock控件來設(shè)計軟件可以說是最方便的。用Winsock控件編寫客戶和服務(wù)器應(yīng)用程序，不需要了解TCP/IP的具體細節(jié)。通過設(shè)置Winsock控件的屬性和調(diào)用該控件的方法，可以很容易地連接到遠程計算機并進行雙向的數(shù)據(jù)交換。
參考文獻：
[1] 天津電氣傳動設(shè)計研究所.電氣傳動自動化技術(shù)手冊[M].北京：機械工業(yè)出版社，2011.
[2] 茹志鵑.基于TCP協(xié)議的Socket數(shù)據(jù)通信[J].科技信息，2012 （13）：69，93
udp協(xié)議篇7
關(guān)鍵詞：車輛監(jiān)控系統(tǒng)； GPS； GPRS； UDP
中圖分類號：TN919-34 文獻標識碼：A 文章編號：1004-373X(2011)24-0107-03
Vehicle Monitoring System Based on GPRS Technology
WU Xiao-bin1, DU Dong-gao2
(1. Computer College, Nanjing Institute of Technology, Nanjing 210000, China;
2. College of Information Engineering, Jiaozuo University, Jiaozuo 454003, China)
Abstract： In order to implement the positioning tracking for dangerous goods, passenger, cargo transport vehicles and other special project vehicles, the GPS positioning system and GPRS communication technology are adopted for the achievement of real-time vehicle monitoring system. The data communication between the vehicle terminal and the control center is achieved by taking GPRS communication technology as a carrier of information transmission to display real-time traffic information by GPS positioning and WEBGIS technologies. The system has the advantages of high-speed communication, strong communication format scalability, high communication reliability and strong client controlling capacity to vehicles. The vehicle front-end status and location are displayed by Web page. It is easy for the clients to use the system.
Keywords： vehicle monitoring system; GPS; GPRS; UDP
收稿日期：2011-07-23
基金項目：南京工程學院青年基金資助項目（QKJB2009023）
0 引 言
隨著我國經(jīng)濟的發(fā)展,車輛日益增多,交通運輸?shù)慕?jīng)營管理,貨運、客運的安全管理等,已成為公安、交通系統(tǒng)中的一個重要問題。車輛監(jiān)控系統(tǒng)以全球定位系統(tǒng)（Global Position System,GPS）和GPRS（General Packet Radio Service）通信技術(shù)基礎(chǔ)，它可以將車載單元上接受到的實時定位數(shù)據(jù)通過無線網(wǎng)絡(luò)傳送至監(jiān)控中心服務(wù)器上，監(jiān)控中心計算機再利用地理信息系統(tǒng)的地圖顯示功能，以及信號指令的發(fā)送功能，實現(xiàn)對動態(tài)車輛的跟蹤與調(diào)度控制，從而建立起的一種大范圍、全方位發(fā)揮作用的、實時、準確、高效的綜合車輛調(diào)度和管理系統(tǒng)。系統(tǒng)基于Internet網(wǎng)絡(luò)，將監(jiān)控中心、遠程監(jiān)控終端、數(shù)據(jù)服務(wù)器、無線移動通信網(wǎng)、GPS 車載終端有機地結(jié)合在一起，以Internet服務(wù)器為核心實現(xiàn)分布式監(jiān)控。
1 系統(tǒng)結(jié)構(gòu)
基于GPRS的車輛監(jiān)控信息系統(tǒng)由4個主要部分構(gòu)成,即監(jiān)控服務(wù)中心、車載終端、監(jiān)控終端及無線通信網(wǎng)絡(luò)構(gòu)成；監(jiān)控服務(wù)中心是系統(tǒng)的核心部分，它連接車載終端和客戶端。監(jiān)控服務(wù)中心由Web服務(wù)器，通信服務(wù)器，數(shù)據(jù)庫服務(wù)器構(gòu)成。通信服務(wù)器接受車載終端的數(shù)據(jù)，并將數(shù)據(jù)轉(zhuǎn)發(fā)給Web服務(wù)器和數(shù)據(jù)庫服務(wù)器。該系統(tǒng)結(jié)構(gòu)圖如圖1所示。
2 系統(tǒng)關(guān)鍵技術(shù)
2.1 GPRS通信技術(shù)及UDP數(shù)據(jù)傳輸協(xié)議
在車輛和監(jiān)控中心之間需要通信設(shè)備來發(fā)送或接收信息。通信手段的選擇是監(jiān)控系統(tǒng)的難點和技術(shù)關(guān)鍵。合理的通信方式的選擇可以為監(jiān)控系統(tǒng)的指揮調(diào)度、報警處理提供一個穩(wěn)定、快速的平臺。
車輛監(jiān)控系統(tǒng)使用GPRS網(wǎng)絡(luò)作為傳輸載體。GPRS是一種采用分組交換和傳輸技術(shù)的高效率數(shù)據(jù)傳輸方式。它克服了電路交換速率低、資源利用率差等缺點，最大限度地利用了現(xiàn)有的GSM網(wǎng)絡(luò)資源，提高了傳輸速率。 相對于短消息方式來說，GPRS服務(wù)既提高了質(zhì)量又降低了使用費用。移動車載終端與監(jiān)控調(diào)度中心之間的通信突發(fā)性較強，而每次數(shù)據(jù)量較小，使用GPRS網(wǎng)絡(luò)作為其傳輸載體是目前比較理想的解決方案，GPRS通信主要分為TCP和UDP協(xié)議。
TCP和UDP協(xié)議同在傳輸層，由于本系統(tǒng)每次傳輸?shù)臄?shù)據(jù)量小而且突發(fā)性強，所以采用UDP協(xié)議傳輸數(shù)據(jù)。UDP協(xié)議的主要作用是將網(wǎng)絡(luò)數(shù)據(jù)流壓縮成數(shù)據(jù)報的形式。一個典型的數(shù)據(jù)報就是一個二進制數(shù)據(jù)的傳輸單位。UDP協(xié)議為不可靠的傳輸協(xié)議，不提供數(shù)據(jù)傳送的保障機制。如果在從發(fā)送方到接收方的傳遞過程中出現(xiàn)數(shù)據(jù)報的丟失，協(xié)議本身并不能做出任何檢測或提示。因此，必須在應(yīng)用層的協(xié)議中添加保障信息傳輸可靠性的確認機制。監(jiān)控中心向終端下傳數(shù)據(jù)時，要求終端返回接收正確或錯誤的確認信息，監(jiān)控中心收到正確的確認信息后數(shù)據(jù)下傳進程才完畢。否則，監(jiān)控中心將在規(guī)定的時間內(nèi)重發(fā)，直到收到正確的確認信息或發(fā)送次數(shù)標志溢出才終止。
GPRS網(wǎng)絡(luò)UDP端口資源十分緊缺，變化很快；UDP由于自身特點，以及GPRS網(wǎng)絡(luò)UDP端口資源的有限性，在一段時間沒有數(shù)據(jù)流量后，端口容易改變，產(chǎn)生的影響就是從服務(wù)器中心端向GPRS終端發(fā)送數(shù)據(jù)，GPRS終端接收不到。原因是移動網(wǎng)關(guān)從中做了中轉(zhuǎn)，需要隔一定時間給主機發(fā)UDP包來維持該IP和端口號,這樣主機就能主動給GPRS發(fā)UDP包，筆者在測試中發(fā)現(xiàn),這個間隔時間很短,約1 min發(fā)一次UDP包才能夠維持,再長時間移動網(wǎng)關(guān)那邊就要丟失這個端口了,逾期主機想主動發(fā)數(shù)據(jù)給終端,將無法送達。只有GPRS終端設(shè)備重新發(fā)一個UDP包過去,移動再分配一個中轉(zhuǎn)IP和端口,才能夠進行雙向通信。為保證端口有效性和數(shù)據(jù)實時性，終端設(shè)備每5 s發(fā)送一條包含定位和狀態(tài)的數(shù)據(jù)給服務(wù)器。
2.2 基于C＃發(fā)送、接收UDP數(shù)據(jù)包使用的主要方法
(1) UDP數(shù)據(jù)類。用Visual C＃實現(xiàn)UDP協(xié)議，最為常用，也是最為關(guān)鍵的類就是UdpClient，UdpClient位于命名空間.Sockets中，Visual C＃發(fā)送、接收UDP數(shù)據(jù)包都是通過UdpClient類的。UdpClient類主要有以下幾個方法，見表1。
（2） 接受終端UDP數(shù)據(jù)。接收UDP數(shù)據(jù)包使用的是UdpClient中的“Receive”方法。此方法的調(diào)用語法如下： public byte ［］ Receive ( ref IPEndPoint remoteEP )； 參數(shù)remoteEP 是一個IPEndPoint類的實例，它表示網(wǎng)絡(luò)中發(fā)送此數(shù)據(jù)包的節(jié)點。下面就是通過偵聽本地端口號“8080”來獲取信息代碼：
UdpClient server = new UdpClient (8080);
IPEndPoint receivePoint = new IPEndPoint (IPAddress.Any,0);
byte［］ recData = server.Receive ( ref receivePoint );
recData就是接受到的UDP報文，其中UDP包頭結(jié)構(gòu)如下：源端口16位，目的端口16位，長度 16位，校驗和 16位；上文中闡述了GPRS的UDP端口非常緊缺，隨時會變化，在每次接受到UDP報文后，必須記錄源端口、IP地址。receivePoint參數(shù)是引用類型，receive到新的UDP后，receivePoint對象的address和port屬性值就是發(fā)送源的IP地址和端口。這個IP和端口未必是真的終端的IP和端口。因為終端上的應(yīng)用程序綁定本地一個端口(比如是9002)，通過這個端口發(fā)送請求給路由器，路由器由此記錄下終端的內(nèi)網(wǎng)IP和端口(9002),然后路由器分配自己的一個空閑端口(比如是7000)，通過這個端口(7000)發(fā)送請求給監(jiān)控中心。而對于監(jiān)控中心，它沒有任何關(guān)于終端的信息，它要做的只是回信息到路由器的外網(wǎng)IP的7000這個端口。路由器收到發(fā)送到其7000端口的數(shù)據(jù)后會再轉(zhuǎn)發(fā)給終端。
（3） 發(fā)送UDP數(shù)據(jù)報。發(fā)送UDP數(shù)據(jù)報使用” Send”方法。“Send”方法的調(diào)用語法如下：public int Send ( byte［］ dgram,int bytes,IPEndPoint endPoint )； 參數(shù)說明：dgram 要發(fā)送的 UDP 數(shù)據(jù)文報（以字節(jié)數(shù)組表示）。bytes 數(shù)據(jù)文報中的字節(jié)數(shù)。 endPoint 一個 IPEndPoint，它表示要將數(shù)據(jù)文報發(fā)送到的主機和端口。 返回值是已發(fā)送的字節(jié)數(shù)。下面使用UDPClient發(fā)送UDP數(shù)據(jù)包的具體的調(diào)用例子：
string IP =receivePoint.Address.ToString();
int Port = receivePoint.Port;
//receivePoint在上文中描述過，為Receive接受UDP時的引用；
IPEndPoint host = new IPEndPoint (IP,Port)；
UdpClient.Send ( "發(fā)送的字節(jié)","發(fā)送的字節(jié)長度",host )；
該代碼實現(xiàn)了對某終端發(fā)送UDP報文后的回復。如果需要主動向終端發(fā)送報文則需要從數(shù)據(jù)庫中提取該終端最近一次的IP和端口號，調(diào)用該方法發(fā)送內(nèi)容。
2.3 數(shù)據(jù)封裝和轉(zhuǎn)存
監(jiān)控中心與客戶端的數(shù)據(jù)通信包含2種：一種是上行數(shù)據(jù)，一種是下行數(shù)據(jù)。上行數(shù)據(jù)包含終端匯報車輛的狀態(tài)信息，車輛實時信息，車輛語音信息，視頻信息等。下行信息包含對終端的回應(yīng)，車輛的實時控制等信息。數(shù)據(jù)種類大約一百多種，可分為20多種格式。針對每種格式定義一個結(jié)構(gòu)進行數(shù)據(jù)接受和轉(zhuǎn)存到數(shù)據(jù)庫，進行數(shù)據(jù)顯示和分析。終端返回數(shù)據(jù)一般是結(jié)構(gòu)類型，為保證數(shù)據(jù)轉(zhuǎn)換準確和便捷，C#也使用同樣的結(jié)構(gòu)對數(shù)據(jù)進行接受。上文中UDP報文接受到的正文是byte類型，該byte內(nèi)容有報文頭和報文類型、校驗部分和正文構(gòu)成。根據(jù)報文類型找到對應(yīng)的C#結(jié)構(gòu)體structType。利用Marshal.SizeOf(structType);獲取結(jié)構(gòu)體大小，并進行分配空間：IntPtr structPtr = Marshal.AllocHGlobal(size); 然后將byte數(shù)組拷到分配好的內(nèi)存空間： Marshal.Copy(recData,0,structPtr,size); 將內(nèi)存空間轉(zhuǎn)換為目標結(jié)構(gòu)體object obj = Marshal.PtrToStructure(structPtr,structType)。為提高系統(tǒng)的實時響應(yīng)速度，這些數(shù)據(jù)分為2種處理方式，如非緊急數(shù)據(jù)直接保存到數(shù)據(jù)庫，而如果是緊急數(shù)據(jù)，比如車輛報警數(shù)據(jù)，車輛控制數(shù)據(jù)則直接通過Socket連接發(fā)送到Web服務(wù)器，由Web服務(wù)器推送到瀏覽器監(jiān)控端。
3 結(jié) 語
本文主要分析了監(jiān)控系統(tǒng)的GPRS通信技術(shù)，詳細介紹了基于GPRS的UDP數(shù)據(jù)通信流程和方法，實現(xiàn)了C#環(huán)境下接受，發(fā)送UDP數(shù)據(jù)報文，協(xié)議的定制，數(shù)據(jù)轉(zhuǎn)存等關(guān)鍵技術(shù)。本文解決的問題是監(jiān)控系統(tǒng)的核心內(nèi)容，但并不是全部，一個完整的系統(tǒng)還應(yīng)包括終端硬件設(shè)計以及后臺監(jiān)控軟件、GIS地圖顯示等許多方面。今后，應(yīng)通過進一步的研究，解決系統(tǒng)其他相關(guān)技術(shù)。
參 考 文 獻
［1］ LAGRANGE X.GSM網(wǎng)絡(luò)與GPRS ［M］.北京:電子工業(yè)出版社,2002.
［2］ 鐘章隊.GPRS通用分組無線業(yè)務(wù)［M］.北京:人民郵電出版社，2002.
［3］ 李德仁.論空間信息與移動通信的集成應(yīng)用［J］.武漢大學學報,2002,27(1):15-17.
［4］ 楊東凱.北京公交GPS車輛監(jiān)控系統(tǒng)研究 [J ].電子技術(shù)應(yīng)用,2000(11):59-61.
［5］ ELLIOTT D K.GPS原理與應(yīng)用 ［M］.北京:電子工業(yè)出版社,2002.
［6］ 翟戰(zhàn)強.基于GPRS/GPS/GIS 的車輛導航與監(jiān)控系統(tǒng) [J ].測繪通報,2004(5):9-11.
［7］ 何小衛(wèi),王愛華,馬躍.基于GPRS的GPS車載終端通信技術(shù)研究［J］.計算機應(yīng)用,2008,28 (11):2952-2954.
［8］ 王緩緩,李虎,張友純.基于GPS的車輛管理系統(tǒng)的難點及解決方案［J］.計算機應(yīng)用,2003,23(12):292-294.
［9］ 明日科技有限公司.Visual C#開發(fā)技術(shù)大全［M］.北京:人民郵電出版社,2007.
［10］ 石超，孫保華，魏云飛，等.GPS接收機低噪聲放大器設(shè)計［J］.電子科技,2010(3)：56-58.
udp協(xié)議篇8
【關(guān)鍵詞】網(wǎng)絡(luò)測量；時延；測量技術(shù)
0 引言
隨著Internet的發(fā)展，其規(guī)模迅速擴大、網(wǎng)絡(luò)業(yè)務(wù)不斷出現(xiàn)、網(wǎng)絡(luò)拓撲結(jié)構(gòu)日益復雜。但具有開放、分布式、不協(xié)作、異構(gòu)等特點的因特網(wǎng)有效管理和控制變得更難。人們致力于在各種情況下尋找和建立連接，主要關(guān)注分組向那里發(fā)送，而較少關(guān)注發(fā)送分組的時間。分組到達的時間時延大大影響了因特網(wǎng)的服務(wù)質(zhì)量。要提高網(wǎng)絡(luò)服務(wù)質(zhì)量，就要找出存在問題。當前的網(wǎng)絡(luò)性能測量評價指標包括：時延、流量、丟包率、吞吐量（帶寬）等。其中網(wǎng)絡(luò)時延是最重要、最常用的性能指標。
1 網(wǎng)絡(luò)時延的基本概念和時延測量原理
時延是指一個報文或分組從一個網(wǎng)絡(luò)的一段傳送到另一端所需的時間。時延由發(fā)送時延、傳播時延和處理時延組成。發(fā)送時延是節(jié)點在發(fā)送數(shù)據(jù)時使數(shù)據(jù)塊從節(jié)點進入傳媒所需要時間，也就是數(shù)據(jù)塊的第一個比特開始發(fā)送算起，到最后一個比特發(fā)送完畢所需時間，也稱為傳輸時延。處理時延是指數(shù)據(jù)在交換節(jié)點為存儲轉(zhuǎn)發(fā)而進行必要的處理所花費時間。
2 時延測量中的關(guān)鍵技術(shù)和影響因素
時延測量首先要消除測量中出現(xiàn)的隨機性。網(wǎng)絡(luò)分組的時延是一個隨時間變化的隨機變量，由固定時延和可變時延兩部分構(gòu)成。固定時延是基本上不變的，它由傳輸時延和傳播時延構(gòu)成。傳輸時延由分組大小和鏈路的容量決定，一個分組的大小一旦固定，通過的鏈路容量便是固定的，其傳輸時延也是固定的。傳播時延由固定的物理傳輸介質(zhì)確定并且是固定的。分組時延中的可變時延是由很多因素造成的。它可以分成中間路由器處理時延和排隊等待時延兩部分。對于任何一個分組，中間路由器總要對其進行路由查表以確定其轉(zhuǎn)發(fā)端口，這個時間可以看成是處理時間。同時，中間路由器繁忙可能導致分組排隊等待處理，也需要一段等待時間。處理和等待時間是不固定的，由路由器的具體性能以及鏈路的擁塞狀況而定，是一個隨機變量。所以如果鏈路不出現(xiàn)擁塞，一個分組的最小時延便與該分組的大小成線性關(guān)系。分組的時延具有突發(fā)性和偶然性，為了能夠使測量結(jié)果盡可能地反映網(wǎng)絡(luò)的真實情況，可以采用低通濾波的方法來消除隨機性。
其次，對網(wǎng)絡(luò)時延的測量，必須保證網(wǎng)絡(luò)入口點和出口點時鐘同步。如果時鐘不同步，則時延測量會有很大誤差。網(wǎng)絡(luò)中路徑往往是非對稱的，或者即使路由是對稱的但往返具有不同的性能特征。單向時延測量要求嚴格的時鐘同步。GPS時間同步技術(shù)是當前比較成熟的并在國際上廣泛使用的時間同步技術(shù)。單向時延測量一般要求、成本比較高。在實際的測量中，測量精度不是主要問題。網(wǎng)絡(luò)時延通常在數(shù)十到數(shù)百毫秒范圍內(nèi)，測量存在幾毫秒的誤差完全可以接受。因此測量方案都采用往返時延，可以避開時鐘同步問題。
網(wǎng)絡(luò)時延總是隨著網(wǎng)絡(luò)的運行狀況而不斷變化。通過分析，可將影響網(wǎng)絡(luò)時延測量的因素歸為兩類：1）網(wǎng)絡(luò)本身的性能，即完全獨立于網(wǎng)絡(luò)測量方法、僅與網(wǎng)絡(luò)本身特性相關(guān)的部分；2）測量報文的特定性能，與網(wǎng)絡(luò)具體的測量方式密切相關(guān).
目前，基于端到端的網(wǎng)絡(luò)時延測量方法，能達到快速準確的目的。這種方法，不是單個設(shè)備的時延測量，而是某一段甚至某一跳之間鏈路的時延測量。端到端往返時延的計算時間都在同一臺計算機上，不存在時間同步問題，無需在測量的兩端都安裝測量軟件，只需要固定一個測量點，另一個測量點可以任意選擇，使測量范圍擴充到整個因特網(wǎng)。端到端傳輸優(yōu)點是鏈路建立后，發(fā)送端知道接收設(shè)備一定能收到，而且經(jīng)過中間交換設(shè)備時不需要進行存儲轉(zhuǎn)發(fā)，因此時延較小。端到端傳輸缺點是直到接收端收到數(shù)據(jù)為止，發(fā)送端設(shè)備一直要參與傳輸。如果網(wǎng)絡(luò)時延很長，那么對發(fā)送端設(shè)備造成很大浪費。端到端傳輸?shù)牧硪粋€缺點是如果接收設(shè)備關(guān)機或故障，那么端到端傳輸不可能實現(xiàn)。在端到端網(wǎng)絡(luò)時延測量中，要降低這種缺點帶來的影響，就要選擇合理的測量時段、數(shù)據(jù)包字長和測量樣本等。
3 網(wǎng)絡(luò)時延測量方法
根據(jù)網(wǎng)絡(luò)時延測量其承載數(shù)據(jù)包的協(xié)議不同，網(wǎng)絡(luò)時延測量方法可分為：基于ICMP協(xié)議的網(wǎng)絡(luò)時延測量。Ping是基于ICMP請求應(yīng)答報文開發(fā)的應(yīng)用軟件，用來診斷網(wǎng)絡(luò)故障，也是用來測量往返時延最常用的工具。Ping工具通過向網(wǎng)絡(luò)定地址發(fā)送ICMP echo報文，并監(jiān)聽回應(yīng)報文，根據(jù)回應(yīng)報文的探測結(jié)果，來評估主機路徑的可靠性、往返時延大小等。將報文封裝在ICMP報文中是目前網(wǎng)絡(luò)測量工具最常用的方式，但是ICMP報文也是用來進行DOS攻擊的主要方式，因此在許多ICMP協(xié)議都被過濾了，可能會完全被阻塞。路由器可以限制ICMP回復的速率來避免被消耗過多的網(wǎng)絡(luò)帶寬和路由資源。這意味利用ICMP協(xié)議測量時延的結(jié)果是不可靠的?；赨DP協(xié)議的網(wǎng)絡(luò)時延測量。當對方主機或者中間節(jié)點過濾掉ICMP報文后，可以使用UDP報文來實現(xiàn)網(wǎng)絡(luò)的往返時延測量。UDP報文的實現(xiàn)和ICMP報文較相似，都是無連接的。不同的是UDP協(xié)議需要指定一個端口，在實際使用時，可以任選一個端口，當接收方該端口對應(yīng)的服務(wù)不存在時，會立即返回一個“端口不可到達”的IC-MP報文。因此，在使用UDP報文進行測量時，要注意發(fā)送方發(fā)送一個UDP報文，接收方反饋的不一定是UDP報文，也有可能是ICMP報文，這兩種返回的報文都可以用來計算網(wǎng)絡(luò)的時延。此外，UDP協(xié)議在實現(xiàn)時要注意其最大報文長度與ICMP報文不同，通常應(yīng)小于500 Byte。但是將報文封裝在UDP報文中也有疑問。UDP沒有TCP協(xié)議所固有的擁塞控制算法，在UDP報文使用達到高峰時，為了減少對TCP流的影響，UDP報文的速率可能會受到限制。
基于TCP協(xié)議的網(wǎng)絡(luò)時延測量。針對防火墻設(shè)置，雖比較復雜，但可適用于測量某些前兩種方法不能工作的特定環(huán)境。除了選取合適的承載報文，TCP協(xié)議測量網(wǎng)絡(luò)時延的難點包括TCP協(xié)議發(fā)送機制本身。TCP協(xié)議為提高傳輸效率，往往不是即時發(fā)送報文，而要收集足夠的數(shù)據(jù)后才發(fā)送，可能會產(chǎn)生發(fā)送方記錄的發(fā)送時間遠遠早于時間發(fā)送時間，而使得測量的結(jié)果大于實際值的現(xiàn)象。為避免此現(xiàn)象的發(fā)生，要求在主動測量時，不但要求發(fā)送方在承載的TCP報文中加入PSH標志，此時將立即發(fā)送此數(shù)據(jù)報文而無需等待，同時也要求接收方在反饋該報文時，也必須帶PSH標志。同理，在被動測量時，要注意承載的報文必須是帶有PSH標志的報文，并且對應(yīng)的反饋報文也必須同樣帶有PSH報文。也可以利用其它協(xié)議實現(xiàn)網(wǎng)絡(luò)時延的測量。方法基本和UDP或TCP類似，關(guān)鍵根據(jù)所在網(wǎng)絡(luò)設(shè)置的具體情況，靈活選擇承載報文，即能在發(fā)送方立即發(fā)送，而接收方收到后又能立即反饋的報文。
4 結(jié)論
本文鏈接：http://www.lbgj202.com/v-141-3373.htmludp協(xié)議范文8篇
相關(guān)文章：
心理健康的手抄報內(nèi)容07-26
給一封情書12-20
最新公務(wù)員試用期轉(zhuǎn)正工作總結(jié)300字(14篇)10-14
創(chuàng)業(yè)項目策劃書07-20
出生證明出生證明07-16
讀《老人的智慧》有感09-12
落葉的小學作文04-07
寫給兒子小學畢業(yè)的一封信04-03
假如我是話題作文03-10
校園落葉作文隨筆01-31