udp协议范文1
关键词：文件传输；FTP；UDP协议；上传；下载；线程
中图分类号：TP368.1
传统的FTP服务中进行文件传输的协议主要是TCP协议，随着互联网应用的越来越普及，以及人们对带宽和传输效率的要求越来越高，传统的FTP服务已经不能满足人们需求的不断增长。本文通过介绍基于UDP协议进行可靠的文件传输实现，较好的解决了对带宽和传输效率方面的需求。
1 FTP上传实现
1.1 登录FTP服务
客户端连接服务端，连接成功后，服务端返回字符串“220 Welcome to FTP Server”。客户端发送用户命令“USER xxx”，Ftpserver返回一个字符串“331 User name ok，need password”。客户端发送密码命令“PASS xxx”。Ftpserver 返回字符串“230 User successfully logged in”登录成功返回的数值必须是230（以上步骤为登录ftpserver，采用标准的ftp命令，上载和下载都是一样的。）客户端发送命令“UPUDPBUF 0”
1.2 创建UDP传输链路
UPUDPBUF表示udp上载方式，0表示normal传输。在这里我们都是使用normal传输方式。Ftpserver返回字符串“200 transfer code Permission”。客户端发送“UDPPORT xxxx”。UDPPORT表示本地开始的udp端口，xxxx表示端口号。返回：”UDPPORT xxxx150 Opening BINARY mode data connection for file transfer.”其中xxxx是ftpserver上的udp端口号码。
1.3 文件分割
参考文献：
[1]张汉萍.点对点报文传输系统的开发[J].科学大众，2007（05）.
[2]马勇.基于UDP多播文件传输方法的研究[J].福建电脑，2009（02）.
[3]周锦才.可靠UDP协议的设计思路与实现方法[J].周口师范学院学报，2006（02）.
[4]冯浩，苏磊.基于TCP的多线程网络文件传输系统[J].软件导刊，2008（08）.
[5]王海军，刘彩霞，程东年.一种基于UDP的可靠传输协议分析与研究[J].计算机应用研究，2005（11）.
udp协议范文2
关键词：arm；linux；交叉编译环境；udp协议；重发机制；重发次数
中图分类号：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协议以其高效性和应用的简单，被广泛运用于嵌入式网络开发中。由于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工具链(ftp://.uk/pub/armlinux/toolchain)
在宿主机上进入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脚本文件等)。[2]由于本实验需对网络编程，要求自动初始化cs8900a网卡芯片的ip地址、网关、子网掩码等，所以在开机自启动脚本中加入ifconfig语句，使得开机时自动配置网卡参数。
根文件系统构建完成后，使用yaffs2文件系统制作工具mkyaffs2image.tgz，通过命令mkyaffs2image rootfs rootfs.img生成根文件系统镜像，然后将镜像烧写入flash中。
4 arm-linux环境下的udp协议通信实验
经过上述硬件设计和操作系统移植过程，本文所使用到的实验环境已经构建完毕，经反复调试修改，嵌入式linux操作系统在平台下运行正常，于是进行udp协议通信实验。
4.1 udp协议套接字编程基础
udp是一个面向数据报和无连接的简单传输层协议，它不像tcp那样通过握手过程建立服务器与客户端的连接才可以工作。在网络通信质量较好的情况下，udp体现出高效率，这适合于传送少量报文的应用。[3] linux系统是通过套接字结构来进行网络编程的，应用程序通过对套接字的几个函数调用，会返回一个用于通信的套接字描述符,而linux应用程序在进行任何形式的i/o操作时，程序实际上是在读写一个文件描述符。[4]因此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.
[2] 范艳开.基于arm的嵌入式linux操作系统移植[d].西安:西北工业大学,2005.
udp协议范文3
关键词：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)。然后将环境变量-linux-gcc所在的目录(编辑/etc/profile 添加语句”export PATH=/user/local/arm/4.3.2/bin:)，然后reboot一下，这样交叉编译环境就构建好了。
3.2 BOOTLOADER的移植
vivi是一款相当成熟和相对简单的常用bootloader，我们以vivi为移植原型，将S3C2440所有IO端口寄存器定义添加到头文件2440add.inc，删除部分硬件平台使用不到的代码，最后将修改过的vivi制作成镜像烧录到flash中。[1]
udp协议范文4
关键词：arm；linux；交叉编译环境；udp协议；重发机制；重发次数
udp协议以其高效性和应用的简单，被广泛运用于嵌入式网络开发中。由于udp协议的应用简单，在嵌入式设备开发过程中，网络资源的利用率并不高。以下将介绍一个udp具体项目实验过程，描述arm-linux环境的软硬件环境构建过程，并对udp协议下一种重发模式中上位机的重发次数的确定提出一种可行的方法。
1 研究背景
随着嵌入式技术的快速发展，嵌入式设备已经在许多领域取代了传统的微型机设备。本文的选题主要来自于实习期间承接的一项改造项目：某院校特长生评分系统的改造。项目改造目的有：1) 保留原上位机。2) 改用手持式客户端进行显示及评分操作。3)保留原有网络设备。针对要求，我们使用s3c2440作为硬件平台，移植linux操作系统，并在arm-linux环境下研究了udp协议的通信过程，进行了上位机与嵌入式系统的udp协议通信实验及分析，并给出一种重发机制中的发送次数求法。
2 硬件平台介绍
s3c2440处理速度达到了400mhz，具有较高的性价比。为了提高开发效率，我们采用公司自行研制开发的et-s3c2440开发板。
2.1 et-s3c2440开发板简介
et-s3c2440是公司自行开发的一款arm9架构的实验开发板，其结构框图如图1。
核心板的主要器件有：32mb×2片sdram，64mb norflash，512mb nandflash。设计了启动方式可选，通过开关选择从nandflash或norflash启动。
2.2 实验相关电路说明
底板电路主要功能是输入输出以及网络通讯功能。按键输入部分采用扫描方式获得输入，用一个单向地址锁存器和一个双向地址锁存器与地址总线相连，可以通过扫描地址来获得按键输入。lcd采用三星的3.5寸tft屏作为显示输出设备。网卡芯片选用的是与原设备匹配的10m 的cs8900a，关于cs8900a与s3c2440的硬件连接，有众多资源可供参考，本文不再赘述。
3 系统软件平台的构建
硬件平台搭建完毕后要将操作系统和应用程序在硬件平台上运行起来。以下是对嵌入式linux操作系统移植的过程。
3.1 交叉编译环境的构建
linux 2.6.29.1版本的内核可以登录到下载。本文选择的是arm-linux-gcc-4.3.2工具链()
在宿主机上进入linux系统，切换当前目录到工具链所在目录，新建一个arm目录保存解压后的文件(mkdir /user/local/arm)并将arm-linux-gcc-4.3.2解压到这个目录中(tar jxvf arm-linux-gcc-4.3.2 ?c /user/local/arm)。然后将环境变量$path修改一下，让$path中包含有arm-linux-gcc所在的目录(编辑/etc/profile 添加语句”export path=/user/local/arm/4.3.2/bin:$path”)，然后reboot一下，这样交叉编译环境就构建好了。
3.2 bootloader的移植
vivi是一款相当成熟和相对简单的常用bootloader，我们以vivi为移植原型，将s3c2440所有io端口寄存器定义添加到头文件2440add.inc，删除部分硬件平台使用不到的代码，最后将修改过的vivi制作成镜像烧录到flash中。[1]
3.3 linux内核移植
获取linux-2.6.29.1源代码并解压后，首先修改内核源代码所在目录中的makefile，将系统架构修改为arm(arch ?=arm ),交叉编译工具修改为arm-linux-gcc (cross_compile ?=arm-linux-)，修改输入时钟(arch/arm/mach-s3c2440/mach-smdk2440.c中的函数static void __init smdk2440_map_io中，修改s3c24xx_init_clocks(12000000)此处所用晶振为12m)。修改machine名称(在arch/arm/mach-s3c2440/mach-smdk2440.c文件中的函数machine_start( ),修改为machine_start(s3c2440, “自定义机器名”)，修改nandflash分区信息(arch/arm/plat-s3c24xx/common-smdk.c结构体static struct mtd_partition smdk_default_nand_part[]中保存的是nandflah的分区信息，将其修改为当前使用的分区信息),然后修改nandflash的匹配时间(3c2410_platform_nand_smdk_nand_info smdk_nand_info ={})。
上述内核源代码修改完成后，还需要对一些设备的驱动进行修改。本文使用的nec 3.5寸 320×240液晶屏，硬件平台使用gpg4脚进行背光控制，需要修改lcd背光(/arch/arm/mach-s3c2440/mach-smdk2440.c中static void __init smdk2440_machine_init(void)，将函数中的gpio口配置为gpg4)。关于cs8900a网卡的驱动移植，相关资源很丰富，本文也不再赘述。
本实验中nandflash采用的是yaffs2文件系统，所以打yaffs2文件系统补丁，压缩包为cvs-root.tar.gz。
至此，linux的内核源代码修改工作完成了，下面还需要利用makefile,进行内核配置。
在linux 2.6.29.1内核目录下首先make s3c2410_defconfig使用2410的配置模板来配置2440；然后make menuconfig,这时我们可以在图形化界面中，空格键可改变各个配置选项的被选中状态，根据需要进行配置即可。配置完成后保存好配置，最后进行内核的编译(make dep 建立文件间依赖 make clean 清除编译残留文件make zimage 生成内核压缩镜像文件)。
编译过程完成后会在内核目录arch/arm/boot/下生成zimage内核映像文件，将这个镜像文件烧录到flash中，调试检验，经上述修改后的内核工作运行正常。
3.4 根文件系统的制作
根文件系统是使用busybox-1.13.3来制作完成。下载busybox并解压完成后，修改makefile中的架构为arm架构，编译工具为arm-linux-gcc( arch ?=arm； cross_compile ?=arm-linux-),然后make menuconfig,通过图形界面对busybox进行配置，然后对busybox进行编译(make config_prefix=/opt/studyarm/rootfs install)，在目标目录下会生成目录bin、sbin、usr和文件linuxrc的内容。
基本目录结构生成后，应该在目标目录下建立一些未生成的必要的系统目录如dev、etc、lib等，并通过chmod命令改变目录权限为可写。再将一些必要的动态链接库和静态库拷贝到lib下，然后在dev目录下创建设备节点，最后创建该嵌入式linux系统的初始化配置文件(包括设备列表文件、口令、网络分组组名、hostname主机名、etc/inittab初始化表单、etc/profile环境变量配置文件、用于系统初始化的.bash脚本文件等)。由于本实验需对网络编程，要求自动初始化cs8900a网卡芯片的ip地址、网关、子网掩码等，所以在开机自启动脚本中加入ifconfig语句，使得开机时自动配置网卡参数。
根文件系统构建完成后，使用yaffs2文件系统制作工具mkyaffs2image.tgz，通过命令mkyaffs2image rootfs rootfs.img生成根文件系统镜像，然后将镜像烧写入flash中。
4 arm-linux环境下的udp协议通信实验
经过上述硬件设计和操作系统移植过程，本文所使用到的实验环境已经构建完毕，经反复调试修改，嵌入式linux操作系统在平台下运行正常，于是进行udp协议通信实验。
4.1 udp协议套接字编程基础
udp是一个面向数据报和无连接的简单传输层协议，它不像tcp那样通过握手过程建立服务器与客户端的连接才可以工作。在网络通信质量较好的情况下，udp体现出高效率，这适合于传送少量报文的应用。 linux系统是通过套接字结构来进行网络编程的，应用程序通过对套接字的几个函数调用，会返回一个用于通信的套接字描述符,而linux应用程序在进行任何形式的i/o操作时，程序实际上是在读写一个文件描述符。因此linux下的套接字编程，可以看成是对普通文件描述符的操作，这些操作与被使用的硬件平台无关，这是linux设备无关性的优点。udp协议的通信模型如图3所示。
在上述流程中，客户端所收到的报文被存储在缓冲区中，recvfrom()函数返回了报文存储缓冲区的首地址，我们可以很方便地对这个首地址进行数组操作，从而实现对报文的解码。
4.2 上位机报文结构及重发机制分析
根据项目要求，上位机软件依然保留，我们使用协议嗅探工具对上位机发送的报文进行了嗅探，得到了上位机报文的结构如表1所示。
表1 上位机报文结构
上位机发出的每条报文由32个字节组成，第0位为版本信息。第1……12位为比赛信息和运动员教练信息，是报文的关键信息部分，13……22位为服务器端和客户端的ip地址及端口号信息，23位是上位机对客户端的操作指令代码，24位是相关重发机制的代码，30和31两位是checksum，用来保证数据传输的正确。上位机采用的重发机制是一种上位机按照固定重发次数多次发送同一关键内容报文的机制，其第24位重发机制位被分为高4位和低4位两部分，高四位的内容是当前发送的报文的索引号，每次发送一条新内容的报文时索引号自增1，索引号的取值范围在0x00—0xff范围内循环自增。低四位是重发编号，表示同一索引号的报文正在被第几次重发，固定的重发次数由上位机初始化时设定。
4.3 嵌入式客户端的实验程序设计
针对报文结构，我们对接收端编写实验程序代码，代码的主要功能是从上位机接收报文，将计算出的checksum校验和与收到的校验和对比判断报文是否正确，然后从正确报文中取出主要信息并按照报文中的上位机指令码进行输出。其结构流程图如图3所示。
实验程序经编码、调试后在交叉编译环境中交叉编译，生成arm-linux环境下可执行文件，在目标板上执行。经测试试验程序能够正确接收上位机发来的报文，对报文解码，并能根据上位机命令对关键信息做输出处理。
4.4 对上位机重发次数的研究
进行udp协议通信时，发送端和接收端的状态是相对独立的，发送端不与接收端建立连接，而是不停向接收端发送，为了确保不丢失报文，上位机采取了按固定次数重发相同内容报文的机制。然而这种机制虽然可以有效确保报文不丢失，但是大量冗余数据报被发送，网络资源利用率不高。重发次数越多，冗余数据报越多，效率越低。要想有效保证数据报准确发送的同时又不产生过多冗余数据报，那么重复发送的次数的确定就成为问题的关键。以下给出一种确定上位机重发次数的方法。
假设当前网络状况下，每次报文发送被丢失的概率为p，系统允许接收端报文关键内容丢失概率为q,那么如何确定以上重发机制中的重发次数k呢？
特殊情况下若报文重发次数为2，分别在每条报文重发机制位注明一个索引号和一个重发编号，发送端发送报文的次序应形如 1.1 ,1.2 ,2.1 ,2.2 ,3.1 ,3.2……其中索引号相同的报文关键内容相同，重发编号不同代表同一关键内容报文的不同次发送。因此只有出现连续两次丢失数据报的情况下，报文关键内容才可能丢失。出现连续两次丢失的情况有2种，当x.1 , x.2丢失，此时索引号为x的报文关键信息将全部丢失。当x.2,(x+1). 1丢失，丢失报文的索引号不同，此时不会发生报文关键信息丢失，因此报文关键内容丢失的概率q=p2/2。
当报文重发次数为3,依然在每条报文的重发机制位注明索引号和重发号，发送报文的次序应为1.1 ,1.2 ,1.3 ,2.1 ,2.2 ,2.3 ,3.1 ,3.2……。只有出现连续3次丢失数据报的情况报文关键信息才可能丢失，列出连续3次丢失报文的情况有3种，当x.1 , x.2 , x.3丢失，此时索引号为x的报文信息全部丢失。当x.2 , x.3 ,(x+1).1或x.3 ,(x+1).1 ,(x+1).2丢失时不影响报文的准确传递。因此此时报文关键内容丢失的概率q=p3/3。
推广至一般情况易得当报文重发次数为k时，报文关键内容丢失的概率q=pk/k，移项有kq=pk。于是我们得到求重发次数k的方法
1) 根据网络状况获得报文丢失概率p；
2) 根据客户需求取得报文关键内容的允许丢失率范围q；
3) 分别作出y=px和y=qx的图像；
4) 求得两图像的交点的x坐标，并将x坐标值取整加一即为所求重发次数k。
本文实验中，需求方允许报文关键信息丢失概率q=0.0001,我们分别对上位机发送端和下位机接收端收发的报文进行了统计，在某一固定时间段内，上位机共发送报文19665条，接收端接收报文18636条，传输过程中丢失的报文19665-18636=1029条，当前网络环境下的报文丢失率为，即p=0.0523。据此数值分别作出y=0.0001x的曲线和y=0.0523 x的曲线，取得两曲线交点x坐标为x≈2.78，最后将x=2.78取整加1得到k=3，即上位机对同一数据报的重发次数应该定为3次就可保证系统丢失报文的概率低于0.0001。
5 结论与展望
本文从硬件平台搭建、linux移植以及udp协议编程几个方面介绍了arm-linux环境下udp协议通信的具体实现，并分析了一种在实际嵌入式项目中常用的上位机数据报重发机制，最后对这种机制中的重发次数的确定方法给出了求解过程，为后续的具体项目实施提供了实践依据，也希望为其他应用这种重发机制的嵌入式产品开发者们提供了借鉴。
参考文献：
[1] 李伟.基于arm9的嵌入式linux手持平台的设计与实现[d].武汉:武汉理工大学硕士学位论文,2009.
范艳开.基于arm的嵌入式linux操作系统移植[d].西安:西北工业大学,2005.
udp协议范文5
关键词IPSec;NAT;IKE;UDP封装
1引言
基于IP技术的虚拟专用网（VirtualProfessionalNetwork，简称VPN）是通过Internet平台将局域网扩展到远程网络和远程计算机用户的一种成本效益极佳的方法。随着网络安全技术的飞快发展，越来越多大型企业利用互联网采用IPSec技术建立VPN网络，IPSec已逐渐成为VPN构建的主流技术。IP安全协议（IPSecurityProtocol，简称IPSec）是由互联网工程工业组（InternetEngineeringTaskForce，简称IETF）1998年底规划并制定的网络IP层标准。IPSec不仅可以为IP协议层以上所有的高层协议和应用提供一致性的安全保护，而且除了可用于IPv4之外，也可用于下一代IP协议IPv6。
另外，NAT（NetworkAddressTranslation）技术通过改变进出内部网络的IP数据包的源和目的地址，把无效的内部网络地址翻译成合法的IP地址在Internet上使用。该技术一方面可以把私有IP地址隐藏起来，使外界无法直接访问内部网络，对内部网络起到保护作用；另一方面，它可以缓解由于IPv4先天设计上的不足，而导致的IP地址严重短缺的现状。
但是，被广泛使用的网络地址转换（NAT）设备却制约着基于IPSec技术的VPN的发展，这是因为IPSec协议在VPN中承担保护传输数据的安全性任务。在数据传输过程中，任何对IP地址及传输标志符的修改，都被视作对该协议的违背，并导致数据包不能通过安全检查而被丢弃。但在VPN中运用NAT技术，则不可避免地要将私网地址映射为公网地址，即对IP地址要进行修改。因此，在VPN网络中如何使IPSec和NAT协同工作，实现NAT的透明穿透具有现实意义。
2协议介绍
2.1IPSec
IPSec包括安全协议和密钥管理两部分。其中，AH和ESP是两个安全协议，提供数据源验证、面向无连接的数据完整性、抗重放、数据机密性和有限抗流量分析等安全任务。为了能够将相应的安全服务、算法和密钥应用于需要保护的安全通道，IPSec规定两个通信实体进行IPSec通信之前首先构建安全关联SA。SA规定了通信实体双方所需要的具体安全协议、加密算法、认证算法以及密钥。IKE提供了用来协商、交换和更新SA以及密钥的完整机制。
IPSec定义了两种类型的封装模式——传输模式和隧道模式。传输模式只对IP分组应用IPSec协议，对IP报头不进行任何修改，它只能应用于主机对主机的IPSec虚拟专用网VPN中。隧道模式中IPSec将原有的IP分组封装成带有新的IP报头的IPSec分组，这样原有的IP分组就被有效地隐藏起来了。隧道主要应用于主机到网关的远程接入的情况。
2.2NAT
NAT能解决目前IP地址紧缺的问题，而且能使得内外网络隔离，提供一定的网络安全保障。它解决问题的办法是：在内部网络中使用内部地址，通过NAT把内部地址翻译成合法的IP地址在Internet上使用，其具体的做法是把IP包内的地址或用合法的IP地址来替换。NAT功能通常被集成到路由器、防火墙、ISDN路由器或者单独的NAT设备中。
NAT有三种类型：静态NAT、动态地址NAT、网络地址端口转换NAPT。其中静态NAT设置起来最为简单，内部网络中的每个主机都被永久映射成外部网络中的某个合法的地址。而动态地址NAT则是在外部网络中定义了一系列的合法地址，采用动态分配的方法映射到内部网络。NAPT则是把内部地址映射到外部网络的一个IP地址的不同端口上。根据不同的需要，三种NAT方案各有利弊。
3IPSec与NAT的不兼容性分析
根据协议的定义，我们知道IPSec和NAT两个协议之间存在一定的不兼容性。其不兼容性主要有以下几种形式：
1）NAT对AH的影响
IPSecAH进行验证的时候，处理的是整个IP包，包括源地址和目的地址。如果IPSec通信双方存在NAT设备，NAT设备就会修改外层IP包头的源地址并修改其校验和，这样接收方会因认证失败而丢弃该包。
2）NAT对ESP的影响
TCP/UDP校验和地计算涉及一个虚构的IP包头，该包头含有IP源和目的地址。因此，当NAT设备改变IP地址时也需要更新IP头和TCP/UDP校验和。如果采用ESP传输模式，IP包经过NAT设备时，NAT设备修改了IP包头，但是TCP/UDP校验和由于处于加密负载中而无法被修改。这样，该信包经过IPSec层后将因为TCP协议层的校验和的错误而被丢弃。
另外，由于TCP/UDP校验和只与内层原始IP包头有关，外层IP包头的修改并不对其造成影响，因此采用ESP隧道模式和仅静态或动态NAT的情况下不存在TCP校验和的问题。但是，在NAPT情况下，因为NAPT需要TCP/UDP端口来匹配出入信包，而端口号受到ESP加密保护，所以ESP分组通信将会失败。
3）NAT对IKE的影响
IKE主模式与快速模式中如果使用IP地址作为身份信息，经过NAT后，会导致IKE协商的失败。
IKE协议使用固定目的端口500，当NAPT设备后的多个主机向同一响应者发起SA协商时，为了实现多路分发返回的IKE包，NAPT修改外出的IKE包的UDP源端口。因此，响应者应该能处理端口号并非500的IKE协商请求，但往往NAPT对UDP端口的映射很快会被删除，再协商的过程就将出现一些不可预见的问题，很容易导致NAPT设备无法将协商包送到正确的目的地。
综上所述，IPSec组件对NAT的支持能力如表1所示从表1中可以看出，只有在隧道模式和地址转换情况下才可以实现IPSec数据流的NAT穿越。这一方法既降低了IPSec协议的安全性，又限制了NAT的工作方式，因此在实际应用中可行度较差。
4IPSec与NAT的兼容性要求
在现有的条件下，为了推动基于IPSec的VPN的发展，IPSec和NAT兼容性解决方案需要满足下列要求：
1）可部署性
IPSec和NAT兼容性解决方案作为一个过渡的解决办法必须比IPv6易于部署。应该只需修改主机，无需改变路由器，在短时间内能与现存的路由器和NAT产品协同工作。
2）远程访问
IPSec的一个重要应用是远程访问公司的内部网络。NAT穿越方案必须考虑远程客户端与VPN网关之间存在多个NAT的情况。
3）防火墙兼容性
IPSec和NAT兼容性方案应该避免对IKE或IPSec目的端口的动态分配，使防火墙管理员进行简单的配置，就可以控制穿越NAT的IPSec数据流。
4）可扩展性
IPSec和NAT兼容性方案应具有良好的扩展性，必须保证在大规模远程访问的环境中，在大量远程接入的环境下，同一时间段多个主机和远程安全网关建立连接。
5）后向兼容性
IPSec和NAT兼容性方案中必须能与已有的IPSec实现互操作。穿越方案应该能自动检测是否存在NAT，能判断通信对方的IKE实现是否支持NAT穿越。
6）安全性
IPSec和NAT兼容性解决方案的引入必须保证不得带来新的安全漏洞。
5利用UDP封装法实现NAT的穿透
本文中的解决方案是采用UDP封装法实现NAT的透明穿透，不需要修改现有的NAT网关和路由器。所以该方案具有简单且易于实现的优点，缺点是由于添加了一个UDP报文头，而加大了带宽开销，但相对于目前持续扩大的传输带宽来说，这个UDP报文头的带宽开销可以忽略不计。下面详细讨论其原理和实现过程。
5.1封装格式
UDP封装法是在原有的IP包的IP头和AH/ESP的数据之间再封装一个UDP头，这样封装后的数据包端口值对NAT可见，就可以正确的实现端口转换。UDP封装格式如图1所示。
另外，由于IKE已经使用了UDP的500端口，为了简化配置和避免多个端口带来的安全隐患，UDP封装的ESP也使用该端口。这样就需要采取一定的方法来区分端口500的数据包是IKE消息还是UDP封装的ESP。为了区分两者，我们采用在IKE报头添加Non-ESP标记。在确定存在一个中间NAT之后，支持IPSecNAT-T的对话方开始使用新的IKE报头。
5.2IKE协商过程
IPSec通信实体双方是否采用UDP封装取决于对话对方是否支持该方法以及是否存在NAT设备，这个过程通过IKE协商来完成。在IKE协商过程中增添了新的NAT-D和NAT-OA有效载荷和以及UDP通道类型。
1）新的NAT-Discovery(NAT-D)有效载荷
这个新的有效载荷包含一个散列值，它整合了一个地址和端口号。在主模式协商期间，即IKE协商第一阶段第三、四条消息中，IPSec对话方包括两个NAT-Discovery有效载荷——一个用于目标地址和端口，另一个用于源地址和端口。接收方使用NAT-Discovery有效载荷来发现NAT之后是否存在一个经NAT转换过的地址或端口号，并基于被改变的地址和端口号来确定是否有对话方位于NAT之后。
2）新的NAT-OriginalAddress(NAT-OA)有效载荷：这个新的有效载荷包含IPSec对话方的原始地址。对于UDP封装的ESP传输模式，每个对话方在快速模式协商期间发送NAT-OA有效载荷。接收方将这个地址存储在用于SA的参数中。
3）用于UDP封装的ESP传输模式和隧道模式的新的封装模式
这两种新的封装模式是在快速模式协商期间指定的，用于通知IPSec对话方应该对ESP使用UDP封装。
5.3地址通告和Keepalive包
由于用UDP来封装IPSec分组的思想只解决了NAPT设备不支持AH和ESP通信的问题。例如TCP校验和错误、UDP端口映射的保持等问题还需要辅助方法来解决。
为保证校验和正确无误，通信双方需将自身的原始IP地址和端口发送给对方，即实现地址通告。地址通告的实现通过IKE第二阶段的前两条消息中的NAT-OA有效载荷。因为NAT-OA有效载荷中包含IPSec对话方的原始地址，为此，接收方就拥有了检验解密之后的上层校验和所需的信息。
消息发起者在NAT中创建了一个UDP端口映射，它在初始主模式和快速模式IKE协商期间使用。然而，NAT中的UDP映射通常超过一定时间没用就会被删除掉。如果响应者随后向发起者发送IKE消息却没有提供UDP端口映射，那么这些消息将被NAT丢弃。这个问题的解决办法是通过定期发送Keepalive包，用于后续IKE协商和UDP封装的ESP的UDP端口映射同时在NAT中得到刷新，从而保证通信的正常运行。
6结束语
IPSec作为网络层的安全协议，目前的应用越来越广泛,已成为构建VPN的基础协议之一。而由于IPv6取代IPv4将是一个漫长的过程，NAT设备的广泛存在极大地限制了IP层安全协议IPSec的推广，因此在目前的条件下，UDP封装方法无疑是一种在当前环境下无需修改NAT网关和路由器、简单可接受的解决IPSec和NAT兼容性的方法，具有一定的现实意义。但是该方案还不完善，有待进一步讨论和研究。
参考文献
[1]RFC3022-2001.TraditionalIPnetworkaddresstranslator(TraditionalNAT)[S].
[2]RFC2401-1998.SecurityArchitectureoftheInternetProtocol[S].
[3]RFC2402-1998.IPAuthenticationHeader[S].
[4]RFC2406-1998.IPEncapsulatingSecurityPayload(ESP)[S].
[5]RFC2409-1998.TheInternetKeyExchange(IKE)[S].
[6]RFC3103-2001.RealmSpecificIPProtocolSpecification[S].
[7]AbobaB,WilliamDixon.IPSec-NATcompatibilityrequirements[Z].Internetdraft,draft-ietf-ipsec-nat-reqtstxt,2001
udp协议范文6
【关键词】 UDP/IP协议 RTP/RTCP协议 传输方式
一、UDP/IP协议与RTP/RTCP协议
1、UDP/IP协议。Internet网络对实现不同地域间计算机的相互通讯及基于数据传输的资源共享意义重大。Internet网络所用的协议较多，但使用最频繁的协议是UDP/IP协议。OSI七层网络标准认为IP层是网络层，UDP与TCP是传输层的协议，其中UDP面向无连接，主要完成数据报服务；TCP面向连接，主要完成可靠流服务。（1）UDP属最基本的传输协议，其不具备任何可靠性措施，但其效率相当高。实践表明，UDP为面向交易型的传输协议，其中单次交易仅包含来回2次报文交换，由此免除连接的建立与撤销所产生的费用。（2）TCP主要完成可靠，如采用滑动窗口机制及确认与超时重传机制等，其通常被应用到拥塞处理与流量控制等领域，但运行TCP协议必然加重网络开销，因此传输实时性数据或突然性的大量数据不宜采用TCP协议（如音频流或视频流等）。
2、RTP/RTCP协议。由前文可知，UDP协议具有不可靠性，那么基于UDP的应用程序必须自主解决可靠性问题（如报文重复、丢失、失序等）。连续传输媒体数据阶段，数据接收方与传输方皆应具备处理数据丢失或延迟等问题的能力，因此RTP/RTCP协议的提出具有必然性。（1）RTP主要传输端到端或实时特征的数据，其中包括装载数据的序列计数、标识符、传送监视、时戳等。RTP报文结构的时戳字段主要记录数据包的采样时刻；序号字段主要记录数据包的序号。所以，对音频视频数据用RTP协议进行封装可实现对丢失数据的准确解码。（2）RTCP是RTP的控制协议，其主要完成对数据接收双方传递信息及网络服务质量的监视。RTCP的报文格式包括RR与SR，其中RR由数据的接受者使用；SR由数据的传输者使用。RTCP的通信具有周期性，同时能向数据传输质量提供反馈信息。
二、基于IP网的多媒体数据传输的应用
研究证实，尽管不同的多媒体系统执行者不同的协议，但其皆具有相同的原理。
1、Windows操作系统。考虑到用UDP协议对数据流进行传输，必须采用WinSock（TCP/IP应用接口的标准）无连接的数据报方式，即把数据直接发送到IP层进行打包，注意上一层数据包的字节数必须交下一层子网的最大IP包小。若数据的传输采用广播方式，那么各数据包的字节数应≤512字节，因此应对RTP/RTCP包的字节数进行限制。总体而言，发送端对数据包进行分组封装与发送，接收方再对接收到的数据包进行相仿的封装重组处理，由此确保发送端与接收端的数据格式相同。WINDOW/NT操作系统内基于以太网的多媒体数据流的传输方式包括点对点的单播、点对多点的广播与组播三种。
2、单播传输方式。若WinSock的数据报套接字要实现UDP传输，必须严格执行如下操作步骤：（1）借助函数socket（）创建一个数据报套接字；（2）传输前把数据报套接字与本地主机端口及IP地址捆绑到一起；（3）用函数sendto（）发送数据；（4）用函数recvfrom（）接收数据，注意函数recvfrom（）与sendto（）的语法大致相同。
3、广播传输方式。远程医疗系统及远程监控系统等多媒体系统的应用通常要求对多媒体数据实施点对多点的传输方式。若发送者以点对点的单播传输方式分别向接受者世界发送数据，其势必大幅度增大网络的带宽资源开销，尤其是同一网段分布着多个接受者的情况，网络带宽资源的浪费量更大。由此可见，采用点对多点的广播或组播方式对此情况数据的传输非常必要。目前多数通信子网皆具备广播或组播的服务能力（如令牌环网、以太网等）。广播传输方式的实现步骤具体如下：（1）借助函数setsockopt（）创建一个广播套接字；（2）数据发送时，发送地址应指定到广播地址；（3）数据接收方法与单播相同。
4、组播传输方式。组播传输方式要求把IP数据传送到“一组”地址，由此使Internet网络内同组（特殊的IP地址标识）的全部成员节能受到数据包。组播传输方式具有高效率性，即一个源站可向多个目标站同时发送IP包，但网络拓扑提供的链路仅被使用1次，由此使网络带宽资源被节省。TCP/IP的IGMP协议拥有组播的内容，其中组播可用的地址为224.0.0.0～239.255.255.255。上述多路广播地址通常被用来存放组播路由的信息，但该范围外的多路广播地址均由应用程序设计定完成。
三、结束语
综上所述，随着社会经济的发展及科技发展水平的提高，Internet网络与多媒体技术已成为人们生活工作不可或缺的部分，若把Internet网络与多媒体技术有机结合起来，其必能有效提高数据的传输效率。
参 考 文 献