udp协议范文
时间：2023-03-15 04:07:07
udp协议范文第1篇
关键词:用户数据报协议;通信;报文分析;Sniffer
中图分类号:TP312 文献标识码:A 文章编号:1009-3044(2010)13-3319-02
Use UDP Protocol and Analysis
LIU Peng1, LIU Yan2
(puter Science and Information Engineering College, Guangxi Normal University, Guilin 541004, China; 2.Affiliated Hospital of Guilin Medical University,The Office of Teaching Management, Guilin 541001, China)
Abstract: UDP protocol is a compact, highly efficient protocol has been widely used. The method of how to design communication program with UDP protocol in windows operating system was introduced. Then test communication with the introduced program. The captured packets by Sniffer in communication experimental were analyzed in detail to verify the network model and the network communication program, summed up the advantages and disadvantages of UDP protocol.
Key words: UDP; communication; packet analysis; sniffer
UDP是User Datagram Protocol的简称,是TCP/IP体系结构中一种无连接的传输层协议,提供面向事务的简单不可靠信息传送服务。UDP 协议是 IP 协议与上层协议的接口,用端口号分别为运行在同一设备上的多个应用程序提供服务。它定义在IETF RFC 768中[1]。
UDP是分发信息的理想协议,适用于追求效率且不需要额外可靠机制的情形,如音、视频流媒体分发、高层协议或应用程序提供错误和流控制功能时的快速数据分发。 UDP服务于很多知名应用,如网络文件系统(NFS)、简单网络管理协议(SNMP)、域名系统(DNS)以及简单文件传输系统(TFTP)、动态主机配置协议(DHCP)、路由信息协议(RIP)等。
1 UDP协议使用
在Windows下使用UDP不需要实现RFC 768中定义的UDP细节,封闭的Windows操作系统为用户实现了协议,以动态链接库及API的形式提供给用户程序调用。这种方式方便了程序设计,但也阻止了用户对网络协议的更深理解。为了更加深入研究UDP有必要对传输报文流进行分析;为了更好的分析,需要实现一个使用UDP的通信程序。
在windows下选用VC6.0编译器。服务器端代码如下:
#include //基本输入输出库
#include //网络API函数库
#pragma comment (lib,"WS2_32.lib")/*将WS2_32.lib加入链接,不用再为这个链接文件设置链接选项了*/
void main()
{ WORD wVersionRequested;
WSADATA wsaData;
int err;
wVersionRequested = MAKEWORD( 1, 1 );
err = WSAStartup( wVersionRequested, &wsaData );
if ( err != 0 ) {
return; /* 处理找不到 WinSock DLL.*/}
/* 确认 WinSock DLL 支持的版本 */
if ( LOBYTE( wsaData.wVersion ) != 1 ||HIBYTE( wsaData.wVersion ) != 1 ) {
WSACleanup( ); return;
}/* [3]以上代码为MSDN提供的设计windows下网络程序的标准方法*/
SOCKET sockSrv=socket(AF_INET,SOCK_DGRAM,0);/*AF_INET因特网地址族UDP, TCP, 等.SOCK_DGRAM 基于upd的套接字。*/
SOCKADDR_IN addrSrv;
addrSrv.sin_addr.S_un.S_addr=htonl(INADDR_ANY);/*htonl主机字节序变为网络字节序*/
addrSrv.sin_family=AF_INET;
addrSrv.sin_port=htons(6666);
err=bind(sockSrv,(SOCKADDR *)&addrSrv,sizeof(SOCKADDR)); /*绑定主机从6666端口接受数据*/
if ( err != 0 ) {
return; /* 处理帮定异常*/
} SOCKADDR_IN addrClient;
int len=sizeof(sockaddr);
char recvBuff[200];//接收缓存
char sendBuff[200];//发送缓存
char tempBuff[200];//暂时缓存
while (1){
recvfrom(sockSrv,recvBuff,200,0,(SOCKADDR*)&addrClient,&len); //接收数据
if('E'==recvBuff[0])
{sendto(sockSrv,"E",strlen("E"),0,(SOCKADDR*)&addrClient,len); //发送数据
printf("Communications end\n");
break;
}sprintf(tempBuff,"Recieve From IP %s :%s ",inet_ntoa(addrClient.sin_addr),recvBuff); //格式化
printf("%s\n",tempBuff);
printf("Please input data send to IP %s :\n ",inet_ntoa(addrClient.sin_addr));
gets(sendBuff);
sendto(sockSrv,sendBuff,strlen(sendBuff)+1,0,(SOCKADDR*)&addrClient,len);
}closesocket(sockSrv);
WSACleanup();
}客户端程序头文件及socket初始化和服务器端一样,不同的是socket函数的使用。
//头文件和服务器端一样
void main()
{…
//初始化和服务器端一样
/* 以上代码为MSDN提供的设计windows下网络程序的标准方法,*/
SOCKET sockCleit=socket(AF_INET,SOCK_DGRAM,0);//SOCK_DGRAM 基于upd的套接字
SOCKADDR_IN addrSrv;
addrSrv.sin_addr.S_un.S_addr=inet_addr("192.168.1.103");/*设置目标地址,根据服务器端情况*/
addrSrv.sin_family=AF_INET;
addrSrv.sin_port=htons(6666);//与服务器端一致
char recvBuff[200];//接收缓存
char sendBuff[200];//发送缓存
char tempBuff[200];//暂时缓存
int len=sizeof(SOCKADDR);
while (1)
{printf("Please input data send to IP %s :\n",inet_ntoa(addrSrv.sin_addr));
gets(sendBuff);
sendto(sockCleit,sendBuff,strlen(sendBuff)+1,0,(SOCKADDR*)&addrSrv,len);//发送
recvfrom(sockCleit,recvBuff,200,0,(SOCKADDR*)&addrSrv,&len);//接收
if('E'==recvBuff[0])
{sendto(sockCleit,"q",strlen("q"),0,(SOCKADDR*)&addrSrv,len);
printf("Communications end\n");
break;
}sprintf(tempBuff,"Recieve From IP %s :%s ",inet_ntoa(addrSrv.sin_addr),recvBuff);
printf("%s\n",tempBuff);
}closesocket(sockCleit);
WSACleanup();
}
以上代码可使用VC6.0、VS2005、 VS2008等软件编译器。服务器端的网络地址为192.168.1.102。客户端不限,只要和服务间路由可达即可,本例中使用192.168.1.100。如不想更改服务器端IP地址,只要按照程序注释,根据实际情况更改客户程序的addrSrv.sin_addr.S_un.S_addr变量即可。
2 报文捕获与分析
图1为客户端IP192.168.1.100向服务器端IP192.168.1.103发出数据“test”后,由服务器端的sniffer捕获的报文。
UDP报文为灰色开始的0c 96 1a 0a 00 0d 6d 3e 74 65 73 74 00共13字节。UDP前45开始到67为标准IP报文头共20个字节,报文开头的00到08 00(IP报文头前)14个字节为DLC(Data Link Control)报文头。UDP报文中,0c 96源端口号,两字节,客户端用于接收信息的端口号,不需要回复可用全零。1a 0a 目的端口号,两字节,服务器端的接收端口号。00 0d 数据包长度,两字节,本示例为13。6d 3e 校验和,两字节。74 65 73 74 00 数据包的内容,74 65 73 74 为“test”的ASCII编码,00通过源程序可以发现,为了接收端处理方便多发的一个空字节。
图2为服务器端103接收到“test”后,向客户端发送“received test”数据,由服务器端的sniffer软件捕获的报文。
UDP报文为灰色开始1a 0a 0c96 00 16 b6 78 72 65 63 65 69 76 65 64 20 74 65 73 74 00共22字节。1a 0a源端口号,0b 96目的端口号,与前一报文正好相反。00 16 数据包长度22字节。B6 78 校验和,72 65 63 65 69 76 65 64 20 74 65 73 74 00 是数据报的内容,同样多发了一个空字节。
由协议分析可知,UDP位于IP报文的数据域中,由源端口、目的端口、长度、校验和、和数据域组成,采用明文传递应用数据。如果传递重要信息一定要在应用层加密,否则很容易被窃取。UDP在发送数据时附带自身的端口号,接收时不需要确认,所以可以方便的进行一对一、一对多和多对多的交互通信,这种方式方便但存在缺陷,如果被攻击者知道服务的端口号,控制多台主机向服务器发送大量垃圾信息,可使服务器瘫痪。这是此类协议的共有的弱点。
3 结束语
传输层的UDP协议由于其简洁、高效性而被广泛使用,是一种重要的协议。该文介绍的UDP协议使用方法具有通用性,可作为开发、学习此类软件参考。UDP协议由于没有安全控制,采用UDP协议的系统在提供服务时最好放在防火墙内,由系统对它提供安全保证。
参考文献:
[1] 谢希仁.计算机网络[M].5版.北京:电子工业出版社,2007:108-184.
[2] Stanley B Lippman. JoséeLajoi C++Primer[M].潘爱民,张丽,译.北京:电力出版社,2005.
[4] Behrouz.A.Forouzan Sophia Chung Fegan.Data Communicatins and Networking[M].吴时霖,等,译.北京:机械工业出版社,2007.7,445-472.
udp协议范文第2篇
关键词：UDP协议；广播；多播；Delphi5.0
中图分类号：TP311.1 文献标识码：A文章编号：1007-9599 (2011) 05-0000-01
Implementation of Broadcast and Multicast under the UDP Protocol
Zhang Wei12,Zhang Huanjun1,Cheng Xiao2
(1.Shenyang Ligong University,Shenyang110168,China;
2.Sicong Co.,Ltd.,Xian710043,China)
Abstract:UDP is a very practical and feasible network transmission layer protocols,now widely used in many fields in the future,and will play a greater role.This paper expounds the development environment Delphi5.0 next Broadcast and multicast a software design method.
Keywords:UDP protocol;Broadcast;Multicast;Delphi5.0
在TCP/IP协议族中，有两个互不相同的传输协议：TCP（传输控制协议）和UDP（用户数据报协议）。TCP为两台主机提供高可靠性的数据通讯，UDP为应用层提供了一种非常简单的服务，它只是把称作数据报的分组从一台主机发送到另一台主机，但并不保证该数据报能到达另一端。与TCP相比UDP的优势就在于它排除了信息可靠传递机制，将安全和排序等功能移交给上层应用来完成，极大降低了执行时间，保证了运行速度。单播、广播、组播则表示的是数据在网络中“播放”的形式，是指有一个人能听到还是让特定的人群听得到，还是让所有的人都听的到的区别。一台主机要向网上的所有其他主机发送帧，这就是广播；多播处于单播和广播之间，向属于多播组的多个主机发送帧。
一、广播与多播的实现
下面我们就详细介绍一下Delphi5.0开发环境下广播和多播的实现。软件开发步骤如下：
（一）网络初始化
1.首先初始化WinSock动态连接库，创建Socket套接字，用下面语句绑定发送方Addr：
Addr.sin_family：=AF_INET；
Addr.sin_addr.S_addr：=INADDR_ANY；//本机接收地址设为任意地址
Addr.sin_port：=htons（UDPPORT）； //设定本机UDP端口号
函数htons将端口号由主机字节顺序转换为网络字节顺序，然后将套接字绑定到一个本地地址和端口上（bind），设置为异步选择，设定接收端SockAddrIn：
FSockAddrIn.SIn_Family：=AF_INET；
FSockAddrIn.SIn_Port：=htons（UDPPORT）；//接收端端口设置
2.广播接口设置。广播方式有两种，一种是limited broadcast，广播地址是255.255.255.255；一种是directed broadcast。limited broadcast初始化时代码如下： SetSockopt（FSocket，SOL_SOCKET，SO_BROADCAST，@broadcast，sizeof（broadcast））；
directed broadcast不需要SetSockopt（），以标准的C类网为例，直接发送x.x.x.255就可以了。这种广播只有同一逻辑子网中的机器才能收到，也就是说对方地址应该是x.x.x.y，如果不是，即使在同一物理子网中也是收不到的。当然，这和子网掩码有关。limited broadcast广播的好处是只要在同一子网中的主机，就可以收到这种广播，而不必非要在统一逻辑子网中。例如，如果你的地址是x.x.x.1，那么这种广播，地址是x.y.z.a的主机也能收到。
3.多播接口设置。mreq.imr_multiaddr.S_addr：=inet_addr（pchar（MY_GROUP））；//设定多播地址mreq.imr_interface.S_addr：=htonl（INADDR_ANY）；//设定本机接收端口。
（二）网络数据的读取
flen：=sizeof（FSockAddrIn）；//获取字节长度
FSockAddrIn.SIn_Port ：= htons（UDPPORT）；//设定本机接收端口
Event：=WSAGetSelectEvent（Message.LParam）；//接收到数据后触发消息事件
if Event=FD_READ then
begin
len：=recvfrom（FSocket，buffer，sizeof（buffer），0，FSockAddrIn，flen）；
value：=copy（buffer，1，len）；//网络数据接收，buffer是缓冲区。
（三）网络数据的发送。
首先定义一个string变量和一个integer变量，然后设置远端主机地址：
FSockAddrIn.SIn_Addr.S_addr：=inet_addr（pchar（Edit1.text））；
value：=Content；
len：=sendto（FSocket，value[1]，Length（value），0，FSockAddrIn， sizeof（FSockAddrIn））； //网络数据发送
if（WSAGetLastError（） WSAEWOULDBLOCK）and（WSAGetLastError（） 0）then //网络数据发送异常判断
showmessage（inttostr（WSAGetLastError（）））；
（四）关闭网络接口
CloseSocket（FSocket）；//关闭Socket
二、结束语
经测试，该软件能成功实现UDP协议下的广播和多播。测试结果如图1、图2所示。
图1 UDP广播测试结果图2UDP多播测试结果
参考文献：
[1]袁振武.谢任东.谈Delphi编程中UDP协议的应用[J].科技广场,2008,05
udp协议范文第3篇
关键词:UDP;RUDP;可靠性
中图分类号:TP393文献标识码:A文章编号:1009-3044(2010)16-4379-02
Reliable Improvement Agreement Based on UDP Agreement
YIN Ran-ran
(School of Computer & Information, Hefei University of Technology, Hefei 230009, China)
Abstract: This article will propose and realizes the embedded equipment's authentic data transmission and one kind of new many through the comparative analysis transmission level transport protocols UDP unreliability and the TCP low efficiency in the UDP agreement's foundation transmits the RUDP agreement wireless. The RUDP agreement software module provides based on the news reliable communication function, the correspondence is faces the connection, the first floor uses UDP to take the load bearing agreement.
Key words: UDP; RUDP; reliability
1 TCP协议和UDP协议
1.1 TCP协议
传输控制协议即TCP,尽管它和UDP都使用相同的网络层协议(IP),但它向应用层提供了与UDP完全不同的服务,它提供一种面向连接的、可靠的字节流服务。面向连接意味着两个使用TCP的应用在彼此交换数据之前必须先建立一个TCP连接,数据传输完成后,再经过4次握手终止双方的连接。在数据传输的过程中,TCP还通过对数据的确认、流量控制等手段提高通信的可靠性。
1.2 UDP协议
UDP(User Datagram Protocol),即用户数据报协议。在TCP/IP网络通信中, UDP协议是一种面向无连接的服务。它发送数据以独立的数据包形式,不保证各数据包的发送顺序,也不进行正确性检查,因此,可能出现数据的重发、丢失、失序等现象[2]。使用UDP协议的常见服务有DNS、QQ等。
UDP协议直接向接收方发送数据而不关心对方计算机的状态,因此,它是一种相对不可靠的通信协议。正因为UDP协议不考虑网络数据传输过程中的很多问题,所以能节省了大量的网络状态确认和数据确认的系统资源消耗,从而提高UDP协议的传输速度和网络的利用效率。可是,如果既能充分利用UDP协议的这些优势,又能保证UDP通信的可靠性,网络通信系统的性能将会得到更大程度地提高。
2 RUDP 协议的提出
2.1 嵌入式设备可靠通信面临的问题
面向连接方式的服务功能明显很强大,它能够发挥面向连接的传输所具备的特性,例如流量控制,差错处理以及顺序交付等等,但是面向无连接的服务更适合于某些情况,在网络层上使用IP协议就是一个面向无连接的服务而且这个面向无连接的服务显得更加健壮,因为Internet本身就是一个不稳定的环境,面向连接的服务反而不能很好的运行于其上。
如果使用TCP连接协议实现嵌入式设备之间的数据传输可能带来许多的问题,嵌入式设备之间建立TCP连接并发送数据后,或者接收端向正在请求连接的设备发出SYN+ACK应答报文后,都可能无法接收到终端的ACK报文,在这种情况下发送端一般会重试并等待一段时间后终止这个连接。大量重传数据会进一步加剧网络的拥塞情况,严重时可以使网络及服务器系统崩溃,同时也会对数据传输的实时性产生影响。同时目前嵌入式设备又存在多点分散、数据量小、实时性要求高等特点[3]。本文将在UDP协议的基础上提出并实现嵌入式设备的可靠数据传输。
2.2 嵌入式可靠传输模型的体系结构
RUDP协议软件模块底层采用UDP作为承载协议,提供基于消息的可靠通信功能。根据计算机网络层次体系的概念,RUDP协议的层次模型就是在原UDP/IP协议的传输层和应用层之间加入了RUDP层和标志层。RUDP协议的层次结构如表1所示。
RUDP层的功能是保证数据的可靠传送。由于嵌入式设备通过网络进行消息的收发是处于一个公共网络的环境之中,可能会有大量无用的数据向嵌入式设备进行发送,大量的数据解析会极大地增加嵌入式设备的负担。为了避免这个问题,我们增加了一个标志层,标志层可以让嵌入式设备迅速的判断所接收的数据包是否为有效数据包,如果标志层数据不可识别,则迅速将包丢弃。在可靠传输层进行可靠传输设计和实现,在这一层,我们增加一系列可靠传输机制以保证嵌入式设备之间数据的可靠传输。这样就形成了一个原UDP协议所在传输层和应用层之间加入了一层为保证可靠数据传送而实现的RUDP软件模块和标志层的六层体系结构。从而,在UDP协议的基础上实现一种基于消息的面向连接的,适合嵌入式设备的可靠数据传递机制。
2.3 嵌入式可靠传输模型的基本功能
嵌入式可靠传输模型RUDP主要功能有:
1) 基于消息的收发功能:RUDP的传输层利用基于消息的传输协议,所以不必考虑发送端可以接收多少数据,只需知道能否接收数据即可。
2) 校验和:RUDP的校验和算法采用UDP的校验功能保证数据包的正确和顺序到达。UDP校验和字段是对整个UDP报文头和UDP所带的数据的校验和。
3) 丢弃重复包和保存失序包的功能:每当收到数据包后,便对数据包进行确认。保存未确认的数据包,丢弃已经确认了的重复包。由于UDP传送过程中,收到的数据包的顺序可能会和发送的顺序有一定的区别,所以保存失序包能够有效的减少重发的次数,也就是能相应的减少网络的数据流量。
4) 超时重发功能:RUDP中借鉴TCP中的超时重发机制来保证数据包的可靠传递;同时TCP中的确认延迟功能也得到借鉴,这样可以显著降低网络的流量,提高嵌入式系统的通信效率。
5) 服务器和客户端保活功能:探测收发两端的连接是否正常时嵌入式可靠传输模型中必须要实现的一个功能。如果连接已经出错,若干数据包仍然发送,当超时定时器到时后就会进行数据的重发。如果没有判断收发两端的连接是否正常,则会导致数据无法正常而又高效的发送。
2.4 RUDP协议工作过程
RUDP协议的工作过程是:首先,建立连接。发送方和接收方通过三次握手的方式建立连接(三次握手过程如图1所示)。第三次握手时,发送方发给接收方的数据帧中除了包含对接收方的确认信息之外,还包含将要发送的数据帧总数。接收方收到确认帧后,开始与发送方建立连接。与此同时将根据收到的帧总数设置接收窗口大小并将所有帧序号放入缓存。双方连接建立好后保证了数据发送和接收的同步性。
接着,发送方开始发送数据帧,接收方收到数据帧并进行处理。能够正确接收到的帧序号将会从序号缓存中删除。发送方发送完数据帧后发送“发送完”标志给接收方。接收方收到此标志后,开始扫描帧序号缓存。如果数据帧全部接收到,接收方向发送方发送一“接收完”标志,发送方收到后断开连接。如果序号缓存中有序号则说明有帧丢失,这时接收方将向发送方发出一个带有丢失帧序号的确认帧。发送方收到此确认帧后将重新发送丢失帧。如此重复,直到接收方完全正确接收到数据帧。其工作过程如图2所示。
3 总结
通过分析比较传输层协议TCP和UDP,能够看到它们各自的特点,并分析出它们各自的优势和缺点。结合嵌入式设备数据传输的特点同时针对UDP在可靠性方面的不足进行了改进,简单介绍了RUDP协议的原理和工作过程。通过分析可以看出采用RUDP的效率在嵌入式设备数据传输中要优于UDP协议,这样就可以实现一种更适合于嵌入式设备的可靠数据传递机制。
参考文献:
[1] Wright G R,Stevens W R. TCP/ IP 详解卷2:实现[M].陆雪莹,蒋慧,译.北京:机械工业出版社,1999.
[2] Comer D E. 用TCP/IP进行网络互联[M].张娟,王海,译.卷2.北京:电子工业出版社,1998.
udp协议范文第4篇
为满足设备健康管理的需求，软件系统主要包含4大主要功能模块:数据传输/通信、数据分析、故障诊断及告警、健康评估及寿命预测。(1)数据传输/通信模块。接口模块通过UDP将采集到的实时运行状态数据传输给服务器，速度最高可达到每10ms传输一次。(2)数据分析存储模块。服务器将接收到的实时数据解析后存入数据库，并根据需要进行处理。由于数据传输过快，若接收到数据后直接存入数据库，时间＞10ms，无法达到要求。因此，需在通信和存储之间设计了一个中间缓存，使两者互不干涉同时作业。(3)故障诊断及告警模块。当某些信息的采集值超过正常范围时，系统应及时做出报警反映，并生成报警记录，通知监测者及时采取措施排除故障。例如电源监控接口模块中的28～60V直流监控模块(JK2860－1)，模块自身工作电源+28V。被控电源输入电压28～60V，输出电压28～60V。当低于28V时，系统会提示欠压警告;当高于60V时，系统会提示过压警告。(4)健康评估及寿命预测功能模块。根据各状态信息对设备进行健康评估，分析设备的性能趋势。当设备出现恶化征兆时，发出告警提示相关人员。使用各种模型对设备的寿命进行预测，当预测显示设备寿命将尽时，发出告警并及时更换设备从而减少不必要的损失。寿命预测界面如图3所示。
2UDP协议
用户数据包协议rDatagramProtocol)，UDP，其是OSI参考模型中的一种无连接传输层协议，可提供面向事务的简单不可靠信息传送服务，资源消耗小、处理速度快，但容易出现丢包的缺点。系统中，由于仅用于监控设备的健康状态，每次传输的数据量小且突发性强，对数据传输可靠性要求较低，而客户端有多台设备与服务器相互通信，故适合使用UDP协议。
3应用UDP协议进行设备通信
系统选择C/S结构并采用vs2005工作平台开发。VisualStudio2005基于.NET2.0框架，其同时也可开发跨平台的应用程序，包括了完备的编码、调试、测试和功能。服务器端在与设备进行通信时，所发送的每一个数据包均必须严格按照数据传输协议进行打包。在数据协议中统一按网络接口模块管理8个监控模块，每个监控模块监控3路电源设计。在网络接口模块中对不存在的监控模块不下发指令，在单路监控模块中对不存在的两路被控电源不予操作，但在指令、信息中相应内容统一填“0”。数据传输协议包括控制指令包、保护阈值设置/查询指令包和网络接口模块反馈信息。其中，以控制指令包为例，该包的数据格式如表1所示。在系统开发中，采用WinSock进行编程。服务器与设备通信过程如下:(1)加载套接字库。WSADATAwsadata;WSAStartup(MAKEWORD(2，2)，＆wsadata)。(2)创建套接字并指定套接字的端口号和主机IP地址。(3)调用bind函数将套接字绑定到本地的某个地址和端口上。(4)调用recvfrom函数接收数据包。当接收到数据包后对数据包进行解析处理。
4结束语
基于UDP协议的设备健康管理系统采用VisualStudio2005开发工具及MySQL设计，能较好地对实时状态数据进行存储及分析，实现了故障告警机制和寿命预测的功能，并可及时通知维护人员保养与维护设备。
udp协议范文第5篇
关键词：UDP协议；Socket；网络通信
中图分类号：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适用于网络环境中的进程间通信，它已成为当前许多操作系统的网络API，也是网络操作系统中必不可少的基础功能。随着Linux操作系统和Internet的不断发展，Linux网络环境下尤其是基于UDP的socket通信技术仍广为注目。文章介绍了socket的编程原理，并通过一个Java编写的客户/服务器程序，描述了网络中基于UDP的不同主机上的两个进程之间的socket通信机制。
1 Socket通信机制
Socket（套接字）机制是一种API，是网络应用程序的编程接口。Socket是通过标准文件描述符和其它程序通讯的一个方法。每一个套接字都用一个半相关描述：{协议，本地地址、本地端口}来表示；一个完整的套接字则用一个相关描述：{协议，本地地址、本地端口、远程地址、远程端口}，每一个套接字都有一个本地的由操作系统分配的唯一的套接字号。
根据传输数据类型的不同，Socket主要分为三类：1) 流式Socket（SOCK_STREAM），在这种方式下，两个通讯的应用程序之间要先建立一种虚拟的连接，提供可靠的、面向连接的通信流，它使用TCP协议，从而保证了数据传输的正确性和顺序的。2) 数据报Socket（SOCK_DGRAM），它使用数据报协议UDP，定义了一种无连接的服务，数据通过相互独立的报文进行传输，是无序的，并且不保证可靠、无差错。3) 原始Socket，原始套接字允许对底层协议如IP或ICMP直接访问，它功能强大但使用较为不便，主要用于一些协议的开发。
2 UDP协议的工作原理
UDP协议是一个面向无连接的协议，其连接的建立不必像TCP那样需要服务器端侦听，也不需要有客户机请求连接，属于一种“强制”性的网络连接。UDP提供一对一或一对多的、无连接的数据报服务。该服务对消息中传输的数据提供不可靠的、最大努力的传送，这意味着它不保证数据的到达，也不保证所传送的数据报的顺序是否正确，UDP不重新传输丢失的数据。其主要工作是：将应用程序传输过来的数据分块交给网络层，确认接受到分组信息。
尽管UDP无法像TCP一样提供可靠的数据传输，但UDP并不比TCP缺乏优越性。UDP在传输效率方面比TCP要高一些，而且许多应用程序并不需要保证严格的传输可靠性，比如视频会议系统等，需要实时的交互，但并不要求音频视频的绝对正确。
使用UDP协议传输数据时，首先设置客户计算机的Local Port(本地端口)属性，而作为服务器的计算机只需要设置Remoter Host(远程主机)属性为客户计算机的IP地址或域名即可，并将其Remote Port属性设置为客户计算机上的Local Port属性。使用UDP端口号时，端口提供了用于发送消息的位置，每个端口由一个唯一的编号来标识。当应用程序向另一台计算机发送数据时，UDP生成一个数据头，包括源端口，这些端口提供送达信息所需要的地址。UDP协议还为数据和数据头计算出求和检验的值，在目标计算机中，数据包被传递至UDP协议程序并送到目的地端口。
3 UDP套接字的通信过程
中提供了两个类DatagramSocket和DatagramPacket用来支持数据报通信。DatagramSoc ket用来在程序之间建立传送数据报的通信连接，是数据报通信中的Socket。在数据报实现C/S通信程序时，无论在客户端还是服务器端，都要首先建立一个DatagramSocket对象，用来表示数据报通信的端点，应用程序通过Socket接收或发送数据报。
DatagramPacket则用来表示一个数据报，它是传输数据的载体，封装了数据、数据长度、数据报地址等信息。
采用UDP套接字方式实现C/S的通信程序由客户端和服务器端两部分组成。服务器进程依次按以下步骤进行：1) 调用Socket()创建一个数据报套接字；2) 调用bind()把服务器地址绑定在该套接字上；3) 调用recvform()等待客户进程发来的请求，服务器此时处于无限循环状态；4) 服务进程接收到客户进程所发来的数据报后，进行处理，调用sendto()将处理结果返回给客户进程，返回状态3)，继续监听；5)服务进程调用close()撤消套接字，终止服务。
客户进程则按以下步骤进行：1) 调用Socket()创建一个数据流套接字；2) 调用sendto()向服务器进程发送数据报；3) 调用recvfrom()等待服务器进程返回该处理结果；4) 客户进程调用close()撤消套接字。
4 数据报通信实例
程序由服务器端和客户端两部分组成，服务器端主机中有一个名为“udp_socket.txt”文件，文件中保存了一段英文。服务器端接收一个客户端的请求，就从文件中读取若干个英文字符发送给客户端。当文件中所有内容发送给完毕，服务器端程序将退出。客户端首先构造一个数据报发送给服务器端，然后等待接受服务器端响应，当接收到服务器端的数据报后，显示数据并结束通信。
1) 服务器端程序
public class Server_Th
{ boolean m_q=true;
public void serverWork() throea IOException
{DatagramSocket ds=new DatagramSocket(2000)
//创建端口号为2000的数据报套接字
BufferedReader in=new BufferedReader(new FileReader (“udp_socket.txt”));
while(m_q)
{ byte buf[ ]=new byte[256];//创建缓冲区
DatagramPacket packet=new DatagramPacket (buf, buflength); //创建接收数据报对象
ds.receive(packet);//接收数据报
String dString=null;
if((dString=in.reaLine())==null)
{in.close();
m_q=false;
dString=”Good Morning!”;}
buf=dString.getBytes();//将数据存储到buf中
inetAddress address=packet.getAddress();
//得到客户端IP地址
int prot=packet.getPort();//得到客户端的端口
packet=new DatagramPacket (buf,buf.length, address. port );
//构造要发送数据报
ds.send(packet);//发送数据报
}
ds.close();//关闭
}
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( );
//创建套接字对象
byte buf[ ]=new byte[256];
InetAdress address=InetAddress.getByName(“20.14.30.9”);
//服务器IP地址
DatagramPacket packet=new DatagramPacket(buf,buf. Length,address,2000);//创建要发送的数据报对象
socket.send(packet);//接收数据报
packet=new DatagramPacket(buf,buf.length);
//创建要接收的数据报对象
socket.receive(packet);//接收数据报
String received=new String(packet.getData());
System.out.println(“The string form the server: ”+recerived);
//取得数据报中的数据并显示
Socket.close();//关闭socket
}}
编写程序时客户端和服务器端的DatagramSocket必须用一个端口，因为客户端向服务器端请求时，服务器需要知道从哪个端口监听请求。当数据进行传输时，服务器从接收到的数据报中得到客户端的接收数据的端口，然后将数据报发送到这个端口，客户端则监听这个端口而得到服务器端发送过来的数据报并显示其内容。运行时要先运行服务器端程序，再运行客户端程序。
5 小结
Socket在网络编程方面发挥着很大的作用。UDP是可靠性无法得到保障的协议，但对于质量要求不是很高的网络应用程序，UDP是一个很好的选择。
参考文献：
[1] 张桂珠.Java面向对象程序设计[M].北京:邮电出版社,2006.
[2] 周坤,傅德胜.基于Windows Socket的网络数据传输及其安全[J].计算机工程与设计,2007,28(22):5381-5386.
[3] 赵文清.浅析用Socket的Java语言网络通讯机制和程序设计[J].信息技术,2002(7):66-67.
udp协议范文第6篇
关键词:通信网络;基于样本块的方法;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协议的丢包率一般来说很小,这也就为图像的结构部分的复原提供了重要的保障。基于样本块的图像修复过程如下:
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值越小,恢复效果越差,与原图差异越大。恢复结果如图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.
[6] 卢小宝,王维兰.基于样本块的唐卡图像修复算法的改进[J].计算机应用.2010,30(4):943-946,2010.
udp协议范文第7篇
关键词：可靠UDP；确认重传；滑动窗口
中图分类号：TP311 文献标识码：A 文章编号：1009-3044（2015）09-0071-03
Abstract：In data transmission network， compared with the other protocol， UDP protocol has certain advantages in speed， but there is also the transmission reliability is poor and the problem of lack of congestion control mechanism in this paper， on the basis of the UDP protocol， by adding a simple three-way handshake， confirm the retransmission mechanism， the sliding window mechanism， designed a reliable transport protocol based on UDP， make it between the reliability and efficiency to achieve a good unity and compromise， and implementation of the agreement of the main module has made a detailed description and the actual test.
Key words： reliable UDP； confirm the retransmission； the sliding window
由于传统的数据传输协议所针对的业务不同，在数据传输的速度和可靠性之间不能达到很好的平衡。车险理赔系统中采用的是移动理赔的思想，手持终端机通过移动通信网络和后台中心系统进行数据交互。目前国内的通信事业并不是很发达，信号覆盖率并不全面，移动通信网络的带宽和传输质量会受到地域的影响，为确保理赔现场与后台系统间数据的及时可靠传输，需要基于移动通信的网络环境设计高效可靠的数据传输功能。本章在UDP传输协议基础上，通过应用层封装和可靠性设计的方法，采用数据包的确认重传、流量控制等机制，设计并实现基于UDP协议的可靠数据传输功能。
1 TCP与UDP的对比
TCP和UDP都属于传输层协议，负责承担数据传输的任务[1]。两者之间的主要区别有：
（1） TCP和UDP是传输层的两个协议，它们最大的区别是是否面向连接。TCP，在客户端和服务器端进行通信之前，首先要交换传输层控制信息，为双方的通信做好准备。UDP是一个非连接的协议，传输数据之前双方不建立连接，当传送数据时，简单的抓取来自应用程序的数据，并尽可能快的把数据传送到网络上。
（2） UDP协议的数据传输不需要维护收发状态和连接状态等，与TCP相比，网络有效利用率得到很大的提高。
（3） TCP协议提供数据确认重传、拥塞控制等可靠性保证，UDP协议不提供可靠性保证，也不提供流量控制。
TCP协议由于需要确认的状态和对数据包的操作过多，数据传输的速度不高且网络延迟较大，所以虽然协议可靠但并不适合面向移动通信的数据传输；而UDP协议由于不用建立连接，没有超时重发等可靠机制，网络延迟小且数据传输速度很快。本文设计的理赔系统面向移动通信网络实现理赔现场与后台系统间的数据传输，网络环境不如光纤接入网络稳定可靠，对数据的高效可靠传输有着很高的要求。因此，本章选用UDP协议，并在其基础上，设计了连接确认、数据确认等可靠机制，满足了系统对于高效可靠传输功能的需求。
2基于UDP 改进的可靠传输协议实现
2.1 主要功能模块及任务结构
综合文献【2】的可靠机制描述，可靠UDP数据传输协议的模块结构如图1所示。
从模块结构上看，本模块主要由以下几个任务实现模块功能：
? 通信处理模块
1） 发送方发起数据传输请求，三次握手成功后，发送方进入数据包封装模块。
2） 超时定时器的启动和关闭。
3） 当数据传输结束时，接收方向发送方主动发起传输结束的请求。
? 数据包封装/解析模块
1） 发送方将要发送的的数据按照协商大小分块，排序。
2） 发送方将分块的数据协商的数据报文结构封装成要发送的消息包。
3） 接收方读取数据包后根据协商的数据报文结构拆分数据包，根据数据包的类型读取信息。
? 消息发送/接收模块
1） 发送方判断发送队列和消息队列是否为空后，将要发送的数据包处理后发送。
2） 接收方从接收队列中读取数据包。
? 数据重组模块
1） 由于网络问题，发送方按序发送的数据包不一定会按序到达，所以接收方在经过数据包解析模块读取数据后，根据该消息的字节序号判断是否为乱序的分组。
2） 若是顺序的分组，将分组与以前收到的消息按序排列；若是要求重传的分组，将该分组放入到所应在的位置中。
3） 如果满足重发条件，则向发送方发送重发包请求。
2.2 核心事件处理流程
2.2.1 通信处理进程
通信处理模块中的通信处理进程主要负责三次握手的发起和确认的请求，数据传输结束后结束连接等任务。具体流程见图2。首先，通信的接收方发起握手的请求，即建立一个虚连接，双方必须确保该连接成功建立后才可以进行下一步数据传输的操作。然后，在接收方一端启动定时器，接收方的数据处理进程接收发送方发送的数据，同时接收方根据定时计时器发送反馈消息；或判断接收到的报文数，当达到数据包累积计数器设定的数值时，向发送方发送反馈消息。
2.2.2 发送方发送报文
数据报文的发送，主要是发送方向接收方发送数据报文和消息报文，流程如图3所示，具体的算法为：
if（发送队列非空）
{
从队列中取出消息；
if （消息类型为数据包）
发送数据包；
else 发送确认包；
}
else if （消息队列非空）
{
打包要发送的数据并将数据放入发送队列中；
套接口处当前序号加1；
}
3 实验结果与分析
3.1 开发环境
系统的编程实现是在Windows XP上进行的，使用的编程工具为Visual C++6.0。
3.2 系统测试
3.2.1 测试环境
本测试是是在无线通信网络下进行的，配置了两台计算机用作数据间收发的测试，操作系统为Windows XP。华为E261 3G上网卡两张，用于连接无线网络，测试拓扑结构如图4所示。
3.2.2 测试内容
本测试采用传输不同大小文件的方式来对数据速度进行测试，每次传输重复测试三次，然后取平均值作为参考数据，测试结果见表1和表2。其中，表1是在最大连接速率7.2Mbps环境下的测试结果，表2是在连接速率为2.2Mbps环境下的测试结果。
由表1可见，在移动通信的网络连接环境为7.2Mbps时，当传输1MB的数据时，TCP协议测试耗时9.75s，平均传输速度约为105KB/s；可靠UDP耗时8.25s，平均传输速度约为124KB/s。当传输数据为32MB时，TCP耗时295.89s，平均传输速度约为120KB/s；可靠UDP耗时197.05s平均传输速度约为168KB/s。
由表2可见，在移动通信的网络连接环境为2.2Mbps时，由于连接环境较差，测试文件并不大，当传输0..36s，平均传输速度约为21KB/s；可靠UDP耗时190.81s，平均传输速度约为43KB/s。
由此可得出：
（1） 可靠UDP传输协议的优势随着传输数据量的增大而越来越明显。
（2） 可靠UDP传输协议的优势随着网络环境的变差而越来越明显。
参考文献：
[1] Douglas er. 用TCP/IP进行网际互联――原理、协议与结构（第五版）[M]. 林瑶， 张娟， 王海，等译. 北京：电子工业出版社，2009.
[2] 王珏， 何秋燕， 王露凯.基于UDP 改进的可靠传输协议设计[J].电子世界，2014（22）.
[3] 王继刚， 顾国昌， 徐立峰，等.可靠UDP数据传输协议的研究与设计[J].计算机工程与应用，2006（15）：113-116.
[4] 靳海力.一种增强型可靠UDP的设计及应用[D].合肥：中国科学技术大学，2009.
udp协议范文第8篇
关键词： 网络地址； NAT穿透； NAT类型； UDP打洞
中图分类号：TP393.02 文献标志码：A 文章编号：1006-88228（2014）06-12-03
0 引言
NAT又名网络地址转换，在如今IP地址越来越稀缺的情况下产生，主要为了解决地址重用的问题。众所周知，在TCP/IP协议中，有三个IP地址区域作为私有地址而被专门保留。
1 NAT分类
1.1 基本的NAT
由于内网的IP地址不允许在网络上出现，内部数据包的 IP地址需转换后才能对外发送，所以在同一时间内，全子网内只有小部分IP地址能够对应到外部全球惟一的IP地址[2]。基本的NAT设备将会改变数据包中的原IP地址，但是不会改变数据包中相应的端口数据。
1.2 NAPT
NAPT全名为网络地址/端口转换器，由其名称可以看出凡是经过此设备的IP数据包，不仅数据包内的IP地址会被修改，而且数据包内的TCP/UDP端口数据也会被修改。它可允许内网多个计算机对应一个全球惟一的IP地址[3]。由于端口修改的方法不同，因而又可分为圆锥型和对称型两种。
⑴ Cone NAT（圆锥型）
在一个客户机（拥有私有地址与端口号）与另一个客户机（拥有公有地址与端口号）建立端口映射之后，只要是当前仍然存在会话在利用此端口映射，那么它就可以用这个端口映射继续处理后续的会话。然而，当位于NAT后的主机与外网的主机建立连接之后，NAT接受外部连接的自由程度是不同的，由此可以把此类型进一步分类。但是要注意这个分类一般只适用于UDP传输，因为对于TCP连接，只有在有专门的配置情况下才会建立。Cone NAT分类之后为下面三种情况。
① Full Cone NAT（完全圆锥型）
2 NAT穿透原理分析
若想用软件实现NAT技术，一种方法是通过扩展应用层协议，使其具有NAT路由的功能；另一种方法则是把应用层协议中的私有地址直接修改为公网地址。但是，由于NAT类型的不同，通过修改应用层协议地址[4]的方法并不能通用，尤其当是Symmetric NAT类型的时候，其预先获得的公网地址与实际转换后的公网地址有可能不相同[5]。
NAT穿透需要分析下面三种情况。首先，双方都是Symmetric NAPT。此情况由于端口号分配的不同，不支持穿透。其次，双方都是Cone NAPT。这种情况是我们所期望的，可以进行穿透。最后，两方分别是Symmetric NAPT和Cone NAPT。这种情况稍复杂些，假设A是Symmetric NAT，B是Cone NAT，由文献分析[6]可知，不管是A先连接B还是B先连接A，在一方的NAT接收到数据包后，由于查询自己的映射表无法找到相对应映射项而会将包丢弃，从而导致连接失败。
因此，根据上述分析可以得出，只有当连接两端的设备都为Cone NAT的情况下，才能实现基于UDP协议的内网穿透。
3 UDP打洞技术
当前发展较快的穿透技术是一种借助于公网服务器来完成NAT穿透的技术，称为Hole Punching技术[7]。此技术属于一种中继方案，主要用来解决通信两端都在NAT设备之后的情况，如今这类情况比较常见。与其他解决方案相比，此技术比较简单通用，穿透原理如图5所示。
从图5可以看出，客户机A和客户机B（下面简称A和B）分别向服务器S注册，因此服务器知道了它们的私网地址和转换后的公网地址。在A希望与B建立连接时，A会先向服务器S发送连接请求，服务器S会把B的公网、私网的地址都返回给A，同时还会把A的连接请求和A的公网与私网地址发给 B。至此A和B都能知道彼此的公、私网地址。可知A、B与服务器之间的通讯仅仅是为了打开通往服务器的通道，并通过不断发送消息保持通道的存在。
接下来，当A得知B的公网、私网地址后，A会同时向这两个地址发起连接。如果A和B同在一个NAT之后，B会先在私网地址上收到A的连接请求，这样A与B之间的通讯就不会有NAT的介入；而如果A和B处在不同NAT之后，那么A发往B私网地址的连接将会无法路由或者被错误路由到不相关的终端，从而被丢弃，而A发往B公网地址的连接会顺利到达B所在的NAT。同样，在B得知A的公网、私网地址之后也会发起连接，情况与A相同。
此时，A和B前的NAT设备已经记住了对方的IP地址和端口信息，对彼此处于敞开状态，即被在内部打洞，因此可建立新的对话，建立连接。由于发送的连接数据包都为UDP包，因此被称为UDP打洞技术。而且，建立连接之后，双方的NAT还可以作为中介将对方“介绍”给其他设备[8]，从而降低S的工作量。
综上所述，Hole Punching技术是通过公网Server保存的地址从而使客户机之间能够直接通信。但是，Server只帮助建立连接，而在建立连接之后就不会再介入了。
4 编程测试
既然上述基于UDP协议的穿透主要是靠公网服务器作为连接中介，那么，通信协议是必不可少的。根据上节所述的穿透原理可编写通信协议。我们需要自定义以下几种STRUCT：Client登录时向服务器发送的消息格式、Client注销时发送的消息格式、Client向服务器请求另外一个Client向自己方向发送UDP打洞消息格式、Client向服务器发送的消息格式、客户节点信息格式、Server向Client发送的消息格式、客户端之间发送消息格式。
关于所编写的Server部分，由穿透原理可知，Server端主要负责两件事，一是循环读取客户机登录和注销消息，并记录客户列表；二是循环转发客户P2P连接请求。这里要注意的是，我们应事先定义一个循环最大值（MAXC），防止丢包之后进入无限死循环，下面的Client部分也一样。Client端则主要有三部分：第一，登录服务端，并接收服务器端发送的已登录消息；第二，向外网IP发送消息，若发送超时，则发送一个请求打洞信息到服务器端，此过程循环（MAXC）次；第三，循环读取当前服务器用户。
我们选用Visual C++6.0作为编程环境，进行此穿透实验的仿真实验。
5 实验运行结果
由于此程序只是为了实现穿透通信，因此功能并不是很完善。部分源程序参考相关资料改编。首先需运行服务器端，如图6所示，由图6可见，服务器端可以将已登录用户记录在案，中转连接功能则由后台运行。
由于编程条件的限制，现将服务器端与两个客户机端在同一台电脑上运行，因此要指向的服务器IP为同一个地址。将客户机端分别命名为11和22，先模拟登录客户端主机11，然后模拟登录客户端主机22，所发送信息为“hello！”，两个客户机端的运行结果分别如图7、图8所示。
由图7、图8可见，两个客户端主机已连接成功，并且发送的信息也已送达目的客户机。
根据此实验结果分析，UDP穿透的目的已经达到。根据多次实验分析，由于客户端主机运行背景不同，同一局域网内可能需要在路由器端开通端口映射功能。
6 结束语
本文浅析了NAT的相关分类以及基于UDP协议穿透NAT的相关技术，并根据研究结果将其进行编程实现。该程序主要是根据UDP打洞技术来实现有关NAT穿透的基本功能，程序具有一定的适应性（针对Cone NAT），若结合硬件设施，可实现远程操控，因此有扩展开发空间。NAT穿透技术涉及很多内容，就传输层的穿透而言，本文只限于UDP协议，但就实际而言是不够的。目前网络上使用最多的传输层协议是TCP协议，而在实际应用中，基于TCP协议的穿透比基于UDP协议的穿透复杂的多。综上所述，本文所研究的NAT穿透技术还有待进一步开发与完善。
参考文献：
[1] 余以胜.P2P网络的NAT穿越技术研究[J].微型电脑应用，2012.1：34-36
[2] 张静颐，赵雪岩，陈爱网.基于NAT穿透P2P即时通讯系统的设计与实现[J].电子设计工程，2011.7：96-98
[3] 杜经纬，王春红.在P2P网络环境下基于UDP协议穿越NAT的研究[J].吉林师范大学学报（自然科学版），2012.1：93-94
[4] 刘健，周仲文，刘洋.基于P2P的TCP穿透NAT技术研究[J].网络安全技术与应用，2011.3：40-41
[5] Guha S， Francis P. Characterization and Measurement of TCPTaversal through NATs and Firewalls [EB/0L].http：//nutss.gforge.cis.cornell.edu/pub/imc05-tcp nat.pdf.
[6] 孔令旺.NAT技术及应用浅析[J].科技资讯，2011.32：26-26
[7] 张知青，王碧玉.浅谈网络地址转换（NAT）的三种方式[J].中小企业管理与科技（上旬刊），2011.10：206-207
udp协议范文第9篇
关键词：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.
刘畅,彭楚武.linux下的udp协议编程[j].仪表技术,2006(1).
udp协议范文第10篇
关键词：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.
刘畅,彭楚武.linux下的udp协议编程[j].仪表技术,2006(1).