APP下载

一种精简TCP/IP协议栈的设计与实现

2010-03-14伍瑞卿

电视技术 2010年1期
关键词:描述符网卡接收端

赵 川,伍瑞卿,樊 丰

(电子科技大学 电子工程学院,四川 成都 611731)

1 引言

网络视频传输得到了越来越广泛的应用,如IP可视电话、数字摄像机、网络视频会议、视频监控系统,数字视频播放器/点播机等。在很多应用场合,都需要小型的嵌入式系统来实现[1]。通常,基于DSP的协议栈都移植自LWIP,uIP。而这些协议栈并不针对视频传输设计。视频传输中通常使用UDP协议以保证传输的实时性[2]。但是UDP的传输是无连接的,不可靠的。例如,在H.264中,如果丢掉解码图像需要的参数集或者IDR图像,会造成无法解码的结果。笔者提出了一种针对视频流传输的改进的UDP协议,在确保正确解码的同时,保证了较小的开销和较高的效率。

2 TMS320DM642 DSP开发平台

TMS320DM642(简称DM642)是TI公司的一款专用于数字媒体应用的高性能32位定点DSP芯片。工作主频高达720 MHz,处理能力可达5 760 MI/s(兆指令/秒),外部总线时钟100MHz。DM642集成了64个32 bit的通用寄存器,能够在一个时钟周期内处理4个16 bit的乘法和8个8 bit的乘法。64 bit宽度的EMIF总线,可连接大容量 SDRAM,Flash,ATA等存储器资源。4路PAL/NTSC标准模拟视频输入,1路PAL/NTSC标准模拟视频输出,以及一个支持10/100 Mbit/s自适应网卡的EMAC/MDIO模块,通过寄存器配置可提供一定的QoS保证[3]。因此,该芯片非常适合视频数据的处理和传输。

3 网络驱动程序的开发

网络接口控制芯片主要由 EMAC Control,EMAC,MDIO等模块控制。

3.1 模块主要功能和结构

MAC Control:主要作为DSP与EMAC/MDIO的接口,提供4 kbyte的本地内存空间给EMAC的包缓冲描述符;具有总线仲裁、重启EMAC/MDIO、全局中断使能、中断逻辑控制等功能,与EMAC模块一起初始化。

MDIO:使用有限状态机配置和监控物理层设备(PHY)。

EMAC:用于在网络上发送和接收数据包。而开发设备驱动主要是对该模块编程。EMAC的特点是:1)作为DMA控制器,在DSP内部和外部存储空间之间传送数据;2)连接PHY的介质无关接口(MII);3)8个接收和8个发送通道,提供一定的QoS支持;4)可选的发送CRC校验;5)支持多播、广播和混合模式;6)硬件流控制。

模块框图如图1所示,其中EMAC/MDIO通过中断映射到DSP的11号中断,EMAC通过DSP内存转换控制器读写DSP的内部外部存储空间,模块的控制寄存器通过DSP配置总线映射到DSP存储空间。

图1 模块结构框图

3.2 底层驱动的软件结构

EMAC使用描述符来管理接收和发送缓冲队列。描述符是一个16 byte的内存结构,存储在EMACControl模块中,包含数据包的长度,存放位置等信息[4]。每个描述符表示1个以太网包。每次发送或者接收操作完成,EMAC都会向DSP发送中断,调整描述符队列。

以太网包的接收和发送是通过一个缓冲描述符系统实现的。EMAC提供256个可用的描述符,每个接收或发送通道都有自己的通道描述符结构,用来维系描述符链表。设备驱动取出空的描述符以便EMAC能够将收到的以太网包的数据写入对应缓存,将缓存中的即将发送的数据送出并且清理对应的描述符以便重复利用。

EMAC接收和发送数据的流程如图2和图3所示。

图2 接收流程图

图3 发送流程图

4 精简协议栈的设计与实现

4.1 协议层的结构

嵌入式系统中实现的协议要根据各个系统的特点及功能来设计其独特的TCP/IP协议簇,实现与需要有关的部分,而不使用的协议则省略。在局域网上使用的很多功能,比如路由协议、SNMP都不需要,只使用ARP,IP,ICMP和UDP,可省略应用层协议。在用于视频数据传输的网络中,如果简化协议基于TCP的话,不仅开销较大,丢失分组将会造成播放延时的增大[2]。并且视频流本身具有一定的错误恢复能力,所以本文的协议栈主要以UDP的发送和接收为设计和测试对象。

4.2 存储缓冲的管理

TCP/IP栈和设备驱动使用包缓冲区发送及接收网络包数据。在该协议栈中,开辟32个包缓冲区构成的缓冲池,而以太网帧长度限制在1 514 byte或1 518 byte(加入CRC校验),因此设置每个缓冲为1 536 byte=(1 024+512) byte,这样分配可以对齐Cache边界,保证冲洗(flush)Cache时,不会与其他缓冲区发生冲突,并且节省存储空间。32个包缓冲头使用EMAC的EMAC_Pkt结构。两段缓冲均存放在片外SDRAM中。协议栈的数据处理和底层设备接口使用sk_buff的结构,编码如下:

其中包含1个底层EMAC的数据包指针,这样就可以方便地将EMAC接收的数据包放入协议栈的缓冲中。协议栈中的缓冲skb即是这种结构。

在每次发送1个数据包之前,都要首先分配skb的存储空间。从EMAC的空队列中弹出1个EMAC_Pkt的数据包,并将skb内的这个数据包指针指向它,然后对skb进行操作。在释放skb时,将这个数据包压入空队列中以便继续使用。

每层协议在封装帧头前,在数据区前预留这些帧头的空间,而数据区域不变。这样数据在各层协议之间传递都使用数据指针,从而避免了数据的重复搬移,以提高效率。当提交到下层协议时,将数据指针pskb->data向前移动1个帧头长度。而在接收数据时,每层协议去掉帧头,将数据指针向后移动1个帧头长度。

由于I帧大小一般超过了1 514 byte,需要加入IP分片的功能。首先计算需要分片数,预留该传输层需要的帧头,填入传输层的帧头数据,然后从原始数据复制到pskb->data,剩下的片预留IP层需要的帧头,填入帧头数据后发送。

ARP的实现需要建立1个ARP列表,存放网络中主机(DSP或PC)的ARP信息。在收到1个IP包后,DSP首先发送1个广播包,查找该报文中源IP对应的MAC地址,如果不在列表中,发送ARP请求,在接收到回应后,将MAC地址和对应的IP加入列表。

在以太网层,调用csl中EMAC_sendPacket发送数据。

加入类BSD套接字函数,封装底层函数,包括socket,accept,bind,connect,recv,recvfrom,send,sendto 等, 便于应用程序调用。

5 协议栈的改进

5.1 改进的UDP协议

鉴于参数集和I帧的重要性,为了提高传输的可靠性,保证正确接收端正确解码,并尽量使协议栈简单,采用类似TCP的重传机制,流程如图4所示。

图4 改进的UDP传输

阈值 RTO 采用 TCP 的计算方法[5]:RTO=β×RTT,RTT为平均往返时延。RTT=α×RTTold+(1-α)×RTTnew,RTTold为上一次的平均往返时间,RTTnew为新的往返时间。往返时间可根据发送时刻的绝对时间和接收到接收报告的绝对时间来计算[5],每发送1个序列(IDR帧更新)就计算1次。在小型网络中,为及时重传关键的数据包,取α=0.25,β=1.5。为测试简便,由几次实验估计,取RTO的值为50ms。

如果需要更可靠的传输,可以在接收端每收到1个数据包就发送1个IP数据包,内容为成功接收标志位,用于发送端判断是否重传以及接收端剩余的缓存空间,用于发送端决定是否延迟一小段时间,等待接收端清理出足够的缓存空间再发送数据。

5.2 接收报告的设计

视频流的接收情况需要反馈给发送端以便客户端和服务端的交互,发送速率需要根据接收端接收和解码的速率来进行一些调整以达到匹配,还可以使发送端对出现的问题进行分析和采取一些解决措施。通常的反馈接收报告中设置固定的时间间隙发送接收报告[1],缺乏灵活性,并且该时间需要大量实验来验证,时间太短会导致网络流量增大,时间太长可能无法及时使发送端获得网络状况并由此控制发送端调整发送速率。因此设计在接收端成功接收到参数集和I帧后,或者解码1个序列(下一个IDR帧到来)后,发送1个接收报告。发送端可以根据接收报告检测网络状况及延时抖动,然后相应的调整发送速率。如果在报文中加入各帧解码时间,还可以调整编码的码率,以达到编码和解码的速率的匹配。

为了提高兼容性和扩展性,参照使用RTCP报文的头部,以便其他能够解析RTCP包的应用程序识别。报头格式如图5所示。

图5 报文头格式

图5中,V为版本号,用于识别报文的合法性。P为填充位,为1时表示数据包末位有填充位。RC为报告位,数据包中所含有的报告数目。PT为类型,不同的值代表不同类型的包,可针对不同的用途设计不同内容的报文,以类型区分。例如,用于视频监控(基本档次),用于流媒体播放(扩展档次)等。Len为整个数据包的长度,不包括报头长。每种类型的报文有固定的长度,如果不符合可以直接丢弃。报文内容如图6所示。

图6中,T n为第n帧的传输时间。n由发送端的I帧周期决定,或者由接收端设定。丢包的序号由接收端根据发送的RTP数据包内容决定。丢包率表示从接收到第一个数据包开始的时间内丢掉的数据包总数与累积接收到的数据包的总数的比例。控制标志位为0时,不变;为1时,提高码率;为2时,降低码率;为3时,关掉此连接。

图6 报文内容

6 测试结果

测试使用网线直连DSP和PC,如果PC网卡没有自适应交叉线/直通线功能,则必须制作交叉线来进行测试。

在PC(IP地址为192.168.1.20)上使用控制台ping配置的DSP的IP地址(192.168.1.10),并且使用wireshark软件抓取PC网卡上的数据包。测试结果如图7所示。

图7 wireshark测试结果

首先,PC网卡向DSP发送第1个ping请求,DSP接收到后发送ARP请求,PC回应自己IP对应的网卡地址,DSP回应ping请求。表明ARP协议和ICMP协议正确实现。

在实际视频序列传输中,采用foreman,news的QCIF以及CIF序列测试,解码端能够正确解码播放,并且达到设定的帧率。对于误码重传仿真测试,本文不再详述。

7 小结

基于DSP的视频传输有着广阔的应用空间,笔者提出了一个精简协议栈的设计和实现方法,以及与EMAC底层驱动的连接,并针对H.264视频流的特点做了一些改进。实验证明,该协议栈可满足多种应用需求。

[1]王力生,梅岩,曹南洋.轻量级嵌入式TCP/IP协议栈的设计[J].计算机工程,2007,33(2):246-248.

[2]毕厚杰.新一代视频压缩编码标准——H.264/AVC[M].北京:人民邮电出版社,2005.

[3]Texas Instruments.TMS320C6000 DSP EMAC/MDIO module refer ence guide (Rev.A)[EB/OL].[2009-10-20].http://focus.ti.com/lit/ug/spru628a/spru628a.pdf.

[4]方怀东,陈启美.基于TMS320DM642的嵌入式TCP/IP协议栈的实现[J].电子技术应用,2006,32(9):25-29.

[5]谢希仁.计算机网络[M].4版.大连:大连理工大学出版社,1989.

猜你喜欢

描述符网卡接收端
基于扰动观察法的光通信接收端优化策略
基于结构信息的异源遥感图像局部特征描述符研究
顶管接收端脱壳及混凝土浇筑关键技术
一种设置在密闭结构中的无线电能传输系统
基于多接收线圈的无线电能传输系统优化研究
基于AKAZE的BOLD掩码描述符的匹配算法的研究
Server 2016网卡组合模式
Linux单线程并发服务器探索
利用CNN的无人机遥感影像特征描述符学习
挑战Killer网卡Realtek网游专用Dragon网卡