实时协议数据通信应用（通用3篇）
实时协议数据通信应用 篇1
1. RTP实时传输协议
RTP报文由两部分组成:报头和有效载荷。RTP报头格式如表1所示,其中:
V:RTP协议的版本号,占2位,当前协议版本号为2。
P:填充标志,占1位,如果P=1,则在该报文的尾部填充一个或多个额外的八位组,它们不是有效载荷的一部分。
X:扩展标志,占1位,如果X=1,则在RTP报头后跟有一个扩展报头。
CC:CSRC计数器,占4位,指示CSRC标识符的个数。
M:标记,占1位,不同的有效载荷有不同的含义,对于视频,标记一帧的结束;对于音频,标记会话的开始。
PT:有效载荷类型,占7位,用于说明RTP报文中有效载荷的类型,如GSM音频、JPEM图像等。
序列号:占16位,用于标识发送者所发送的RTP报文的序列号,每发送一个报文,序列号增1。接收者通过序列号来检测报文丢失情况,重新排序报文,恢复数据。
同步信源(SSRC)标识符:占32位,用于标识同步信源。该标识符是随机选择的,参加同一视频会议的两个同步信源不能有相同的SSRC。
特约信源(CSRC)标识符:每个CSRC标识符占32位,可以有0~15个。每个CSRC标识了包含在该RTP报文有效载荷中的所有特约信源。
时戳(Timestamp):占32位,时戳反映了该RTP报文的第一个八位组的采样时刻。接收者使用时戳来计算延迟和延迟抖动,并进行同步控制。
这里的同步信源是指产生媒体流的信源,它通过RTP报头中的一个32位数字SSRC标识符来标识,而不依赖于网络地址,接收者将根据SSRC标识符来区分不同的信源,进行RTP报文的分组。特约信源是指当混合器接收到一个或多个同步信源的RTP报文后,经过混合处理产生一个新的组合RTP报文,并把混合器作为组合RTP报文的SSRC,而将原来所有的SSRC都作为CSRC传送给接收者,使接收者知道组成组合报文的各个SSRC。
在发送端,上层应用程序以分组形式将编码后的媒体数据传给RTP通信模块,作为RTP报文的有效载荷,RTP通信模块将根据上层应用提供的参数在有效载荷前添加RTP报头,形成RTP报文,通过Socket接口选择UDP协议发送出去。在接收端,RTP通信模块通过Socket接口接收到RTP报文后,将RTP报头分离出来作相应处理,再将RTP报文的有效载荷作为数据分组传递给上层应用。
2. G.726语音编码解码算法
G.726作为一个语音压缩的国际标准,主要应用于公用电话交换网PSTN和无线市话接入等音频流的压缩编码和解码,并支持ISDN会议、会议电话等其他低数据传输速率下的应用。
G.726是ITU-T定义的一种音频编码算法,主要基于以16-40kbps比特率运行的。但由于其只是G.711速率的一半,所以可将网络的可利用空间增加了一倍。G.726是ITU前身CCITT于1990年在G.721和G.723标准的基础上提出的关于把64kbps非线性PCM信号转换为40kbps、32kbps、24kbps、16kbps的ADPCM信号的标准。G.726标准算法简单,语音质量高,多次转换后语音质量有保证,能够在低比特率上达到网络等级的话音质量,从而在语音存储和语音传输领域得到广泛应用。
3. 语音通信的实现过程
语音通信过程是全双工的,可以实现一对一和一对多的通信,通信的整个流程如图二所示,利用windows的低级音频API函数族Wave In,Wave Out实现麦克风的数据采集和数据播放;在发送端音频数据采集完成后需要用到G.726语音编码算法进行编码,以提高传输过程中带宽的利用率;根据RTP协议把音频数据封装成RTP包,通过网络传输到接收端。在接收端对收到数据进行RTP包解封装并对音频数据解码,最后得到可以播放的音频数据。
3.1 音频数据的采集和播放
使用低级音频函数实现音频采集与播放,有几个重要的数据结构:波形数据格式WAVEFORMAT,波形数据缓冲区格式WAVEHDR。用到的主要函数有:打开波形输入设备函数wave In Open(),打开波形输出设备函数wave Out Open()。
在录音和放音时,分配内存缓冲区的同时相应分配WAVEHDR数据块结构,然后将缓冲区的指针赋给对应的数据块结构的成员变量lp Data,这样当一个缓冲区填满后,也就是一个音频数据块填满了,通过消息机制就可以在消息函数中进行处理和播放,播放完后又可通过消息函数把缓冲区再送给音频设备输入驱动程序,继续进行采集并播放。所有任务完成后,关闭相应的设备。
使用低层的声音函数对声音进行采集、回放时,声音是存放在一个内存数据块中,当采集缓冲区中数据满时将得到MM_WIM_DATA消息,以及回放缓冲区中数据为空时将得到MM_WOM_DONE消息,用户可以采用相应的消息映射函数来处理相应的过程。
录音开始后,每当有采样数据填满数据块后,设备驱动程序就会发消息MM_WIM_DATA给用户窗口,相应的消息回调函数On Mm Wim Data()对声音数据进行处理,包括播放、存储或者网络发送,每当一个音频数据块播放完毕,设备驱动程序又会发出消息MM_WOM_DONE,相应的消息回调函数OnMm Wom Done()记录音频数据并经必要准备后重新发送给输入设备,以准备接收后续的采样数据。这样,最初为输入设备准备的音频数据块就在消息的控制下,在输入、输出设备间循环使用,无需人为控制实现了实时采集、处理和播放。当结束通话时要关闭音频输入设备,这时音频设备驱动程序会发送MM_WIM_CLOSE消息,可在相应的消息函数On Mm WimClose()中清除赋给输入、输出设备的音频数据块。声音的播放过程与录音过程非常相似,在此不再赘述。
3.2 G.726对音频数据的编码和解码
G.726算法在前面已经介绍过了,在程序中直接调用了g726lib.lib中的函数对数据进行编码和解码。把编译好的g726lib.lib库放在程序的目录下并在工程属性中指定正确的文件路径。
在通信过程中在发送方需要对数据进行编码后发送:
3.3 用RTP协议传输数据
本程序通过RTP协议来传输数据,建立在UDP协议之上。用了开源版的JRTPLib库,其中包含jrtplib-3.8.2和jthread-1.2.1。在vs2008下分别编译这两个函数库,把编译好*.lib文件放到工程目录下,并在工程属性中指定正确的文件路径。
通信双方建立连接之前需要先初始化发送端和接收端的参数,如下代码所示:
在初始化通信参数后添加对方的IP地址后就可以进行通信了,因为语音通信过程是全双工的,可以实现一对一和一对多的通信,所以在添加对方的IP地址时可以通过如下函数添加多个:
m_sess Data.rtp Send.Add Destination(*rtp Addr);
数据的发送:
m_sess Data.rtp Send.Send Packet();
数据的接收:数据的接收是通过虚函数On RTPPacket()来实现的。
virtual void On RTPPacket(RTPPacket*pack,const RTP-Time&receivetime,const RTPAddress*senderaddress);
以上就是通过开源JRTPLib库实现建立连接、数据封装、数据发送和数据接收的过程。
4. 结束语
本文介绍了利用RTP协议进行实时语音通信,其中G.726编码解码算法可以在低数据传输速率下提高通话质量,利用Windows API进行语音数据的采集和播放,可以直接控制声音实时的采集与回放,不需要把声音形成相应的文件,而是把采集到的声音放到内存中,形成一种类似流的存储单元,从而保证了通话的流畅性。
RTP协议虽然目前已经应用于多媒体数据实时传输中,还有一些关键技术有待解决,如:主动自适应调整带宽,实时恢复丢失的报文,多点投递等等。随着对RTP研究的深入,它将在多媒体网络通信中应用越来越广泛。
参考文献
[1]严俊,潘建平.Microsoft Windows环境下RTP协议的实现及其适应性应用的研究[J].数据通信,1999,(2):24-26.
[2]钟玉琢,李树青,林福宗,等.多媒体计算机技术[M].北京:清华大学出版社,南宁:广西科学技术出版社,1993.139～142.
[3]欣力,李莉,陈维,等.M icrosoft W in32程序员参考大全(二)[M].北京:清华大学出版社,1994.383～396.
[4]李博轩.Visuanl C++6.0多媒体开发指南[M].北京:清华大学出版社,2000(2):71～75.
[5]R Braden Ed,et al.RSVP:Resource ReSerVation Protocol—Version1 Functional Specification(RFC 2205)[EB/OL].http://www.ietf.org/rfc/rfc2205.tx·t1997-09.
实时协议数据通信应用 篇2
6.2.1 RTP数据传输协议
RTP提供端对端网络传输功能，适合通过组播和点播传送实时数据，如视频、音频和仿真数据。RTP没有涉及资源预订和质量保证等实时服务，RTCP扩充数据传输以允许监控数据传送，提供最小的控制和识别功能。RTP与RTCP设计成独立传输和网络层。
2.1.1 RTP固定头
RTP 头格式如下：
-----------------------------------------------------------------------------------------------
|V=2|P|X| CC |M| PT | 系列号 |
-----------------------------------------------------------------------------------------------
| 时标 |
-----------------------------------------------------------------------------------------------
| 同步源标识(SSRC) |
-----------------------------------------------------------------------------------------------
| 作用标识 (CSRC) |
| .... |
-----------------------------------------------------------------------------------------------
开始12个八进制出现在每个RTP包中，而CSRC标识列表仅出现在混合器插入时，
2.1.2 复用 RTP 连接
为使协议有效运行，复用点数目应减至最小。RTP中，复用由定义RTP连接的目的传输地址(网络地址与端口号)提供。例如，对音频和视频单独编码的远程会议，每个媒介被携带在单独RTP连接中，具有各自的目的传输地址。目标不在将音频和视频放在单一RTP连接中，而根据SSRC段载荷类型进行多路分解。使用同一SSRC ，而具有不同载荷类型的交叉包将带来几个问题：
如一种载荷类型在连接期间切换，没有办法识别新值将替换那一个旧值。
SSRC定义成用于标识单个计时和系列号空间。如媒体时钟速率不同，而要求不同系列号空间以说明那种载荷类型有丢包，交叉复用载荷类型将需要不同计时空间。
RTCP发送和接收报告可能仅描述每个SSRC的计时和系列号空间，而不携带载荷类型段。
RTP混合器不能将不兼容媒体流合并成一个流。
在一个RTP连接中携带多个媒介阻止几件事：使用不同网络路径或网络资源分配;接受媒介子集。
对每种媒介使用不同SSRC，但以相同RTP连接发送可避免前三个问题，但不能避免后两个问题。
2.1.3 对RTP头特定设置的修改
可以认为，现用RTP数据包头对RTP支持的所有应用类共同需要的功能集是完整的。然而，为维持ALF设计原则，头可通过改变或增加设置来裁剪，并仍允许设置无关监控和记录工具起作用。标记位与载荷类型段携带特定设置信息，但由于很多应用需要它们，否则要容纳它们，就要增加另外32位字，故允许分配在固定头中。包含这些段的八进制可通过设置重新定义以适应不同要求，如采用更多或更少标记位。如有标记位，既然设置无关监控器能观察包丢失模式和标记位间关系，我们就可以定位八进制中最重要的位。
其它特殊载荷格式(视频编码)所要求的信息应该携带在包的载荷部分。可出现在头，总是在载荷部分开始处，或在数据模式的保留值中指出。如特殊应用类需要独立载荷格式的附加功能，应用运行的设置应该定义附加固定段跟随在现存固定头SSRC之后。这些应用将能迅速而直接访问附加段，同时，与监控器和记录器无关设置仍能通过仅解释开始12个八进制处理RTP包。如证实附加功能是所有设置共同需要的，新版本RTP应该对固定头作出明确改变。
实时协议数据通信应用 篇3
硬实时数据具有非常高的时效性。在硬实时通信中,一旦其传输延迟超过了截止时间,就会被认为丢失或者变得毫无用处[1,2]。例如对医疗机器人机械臂的控制信息,任何延迟都可能会造成严重后果; 物流仓库中自动搬运车轮子的控制命令一旦被延迟就有可能拿错货物。
针对交换式工业以太网的实时性问题,目前大量的研究更多集中在骨干网、城域网和局域网的Qo S部署及不同的Qo S技术互操作问题的解决上, 很少涉及以太网技术本身的改进。针对以太网技术本身进行改进的最好方案是在全双工交换式以太网的MAC层引入IEEE802. 1P严格优先权协议[3]。 引入IEEE 802. 1P协议之后,高优先级数据的实时性得到了很大的保障,但仍然存在时延[4]。在一些特殊领域,人们希望硬实时数据的实时性越高越好, 为了进一步提高硬实时数据的实时性,Alimujiang等人在普通以太网的MAC层上增加RT ( real time) 层为硬实时数据开辟实时通道,文献[5]在此基础上将硬实时数据区分开,进行特别处理,有效地提高了硬实时数据的实时性。
在硬实时数据帧到达交换机的时间比较分散的情况下,文献[5]中的方法能够很好地满足工业现场对硬实时数据的传输要求。但是当两个硬实时数据帧到达交换机的时间间隔小于交换机处理单个硬实时数据帧的时间时,就会出现丢包现象。针对这个问题,本文提出了一种保障机制,确保每一个硬实时数据帧都能够及时安全有效的通过交换机,最后利用OPNET对算法进行了仿真验证。
1IEEE802. 1P协议实时性及其改进方法分析
IEEE802. 1P协议是根据队列中数据帧的优先级按照由高到低的顺序进行调度的。所以当交换机中因数据量过大而发生端口竞争时,优先级为P的报文在交换机内缓冲队列中的排队时延应该是以下时间之和[6]:
1正在被交换机处理的报文离被处理完还需要的时间Ta。
2处理队列中比优先级p高的所有报文所需时间。
3处理优先级同为P,但在队列中比该报文靠前的报文所需时间。
4处理该报文所需时间。
该报文在交换机中的延迟时间tdelay可表示为:
其中,i表示优先级,N( i) 表示在端口队列中优先级为i的报文个数,Tsw - tr表示交换机处理一帧数据所需时间,Ting表示处理完正在处理的报文还需要的时间。
由于硬实时数据具有最高优先级,所以其在队列中的延迟时间TH_delay可表示为:
其中,n表示在队列中比该数据帧靠前的硬实时数据帧个数。
若要减少硬实时数据在队列中的延迟时间,需要从三个方面着手:
1尽可能的减小Ta。
2减少队列中的硬实时数据帧个数。
3减小交换机处理单个报文的时间。
2协议改进及保障机制的作用分析
若要使硬实时数据的排队时延达到最小,其优先级必须设定为最高,即优先级为7。硬实时数据具有严格的实时性,所以任何硬实时数据帧都不能被打断。本文采用文献[5]中的协议改进方法,在MAC层中加入RTC层,由RTC层负责通过清除交换机正在处理的非硬实时数据的方式来减小Ta,并控制硬实时数据帧绕开TCP/IP直接进入MAC层处理,减小交换机处理单个报文的时间。加入调度保障机制,利用反馈的方法将交换机正在处理的数据帧实时性和新接收到的数据帧实时性结合起来, 共同决定如何处理新接收到的数据帧。设交换机正在处理的数据帧的优先级为prio,加入保障机制后, IEEE802. 1P协议对数据帧的调度流程如图1所示。
从图1中可以看出: 当数据帧进入交换机后,交换机根据其优先级来判断实时性。如果是硬实时数据,交换机会立即通知RTC层; RTC层根据交换机当前的状态以及Prio的值决定数据的处理方案。 如果交换机空闲,这帧数据会在RTC层的控制下直接进入MAC层; 如果交换机正在处理其它数据,但此数据帧的优先级比较低,交换机会清空正在处理的数据帧,马上去处理硬实时数据帧; 如果交换机正在处理的数据帧的优先级Prio为7,新数据帧就会按照优先级进行排队,等到交换机将当前的数据帧处理完毕后再按照FCFS原则处理队列中的硬实时数据帧。
如果是非硬实时数据帧( 例如软实时数据、日志数据等) ,进入交换机之后将严格按照优先级进行排队。交换机将按照优先级从高到低的顺序对其进行处理。从队列中取出的数据帧经过复制之后并行分为两路: 一路进行同步存储备份,另一路进入交换机TCP/IP层。在交换机处理非硬实时数据帧的过程中,一旦硬实时数据帧到达并被交换机识别, RTC层控制交换机清除正在处理的非硬实时数据帧,直到硬实时数据帧被处理完之后,交换机会从数据存储器中取出刚才被强行清除的一个或几个数据帧重新处理,被清除的数据帧处理完毕之后,再来处理队列中的非硬实时数据帧。
3模拟仿真及分析
本文采用OPNET对改进前后的协议进行仿真验证。OPNET提供了三层建模机制,分别在进程层、节点层和网络层进行由下到上的建模。进程模型用有限状态机来描述各种协议; 节点层由进程模型构成; 网络模型由节点模型组成[7]。
3. 1协议建模
有限状态机使用状态转移图来表示状态的转移,因此为了方便建立进程模型,首先对改进后的协议进行事件建模。将交换机的工作状态分为三个部分: 空闲、忙和等待。协议事件如表1所示[5,8]。
根据协议事件表,利用OPNET的进程模型编辑器对协议进行进程建模,然后依次进行节点建模和网络建模[9]。工作站节点模型和交换机节点模型[10]分别如图2 - 3所示。
图2中,利用src0、src1和src2三个信源模块分别产生硬实时、软实时和普通数据,mac模块中加入改进后的协议,数据经过mac模块处理之后由pt1发送出去。图3中利用三个接收机接收来自三个工作站的数据,然后模拟三个工作站的数据在交换机端口中 产生冲突 时的排队 和由改进 后的IEEE802. 1P协议进行调度的情况,数据经过调度后发给sink模块进行销毁。网络模型由三个工作站节点和一个交换机节点通过1000Mbps的单工链路模型连接。
3. 2仿真验证
硬实时数据帧的优先级设置为最高,start time、 stop time分别为10s和10. 0001s,工作站在这段时间内发送硬实时数据帧。
Packet interarrival time作为变量。仿真结果收集在不同的帧到达时间间隔下,工作站发出的以及sink模块接收到的硬实时数据帧个数和硬实时数据帧从信源模块到sink模块的延时。仿真时间为10min。仿真结果如表2所示。
其中,a、b分别代表文献[5]和本文的方案。交换机处理单个数据帧需要30μs。当包到达时间间隔大于30μs时,两种方案的调度效果相同。当包到达时间间隔小于30μs时,方案a因为缺乏保障机制,先到的数据帧会被后面的数据帧打断而丢失,只有最后一个数据帧能够顺利通过; 方案b虽然会产生延时,但是能够保证所有数据帧可以及时传送出去,不会造成帧的丢失。
图4所示是信源模块随机产生硬实时数据包时,信源模块产生的硬实时数据帧总数( 用“”表示) 以及两种方案中sink模块收集到的硬实时数据帧个数对比图( “* ”和“× ”分别代表文献[5]和本文的方案) 。从图4中可以看出本文方案中sink模块收集到的硬实时数据帧个数和信源模块产生的硬实时数据帧个数完全相等,说明本文方案可以有效避免丢包现象。
4结束语
本文分析了硬实时数据在采用IEEE802. 1P协议的交换机中的排队延时,针对文献[5]中所存在的硬实时数据帧丢失问题,对协议的改进方案提出了一种硬实时数据的调度保障机制,利用反馈的方法实时控制硬实时数据的流向,避免新到的硬实时数据帧打断交换机对当前硬实时数据帧的处理。采用OPNET仿真软件对原方案和加入保障机制后的方案进行仿真分析比较。结果表明,当两个硬实时数据帧到达交换机的时间间隔小于交换机处理单个数据帧的时间时,本文的方案能够很好地避免硬实时数据帧的丢失,有效地保证了硬实时数据的实时性。
摘要：在交换机内部,通过改进IEEE802.1P协议,为硬实时数据开辟一条“绿色通道”,是提高其实时性的一种解决方案。针对这种方案中出现的丢包问题,提出了一种调度保障机制,利用反馈的方法控制硬实时数据的流向,避免新到的硬实时数据帧打断交换机对当前硬实时数据帧的处理。最后利用OPNET仿真软件,对该改进算法进行仿真验证。仿真结果表明,新的调度保障机制可以有效地克服丢包问题,保证硬实时数据的实时性。