基于拓扑感知的流媒体编码和应用层组播系统设计

刘锦康，赵 征

（华北电力大学（保定），河北 保定 071000）

0 引 言

互联网的数据传播方式分为单播、组播和广播三种[1]。在这三种互联网数据传播方式中，单播能够及时响应服务器和客户之间的请求，为网络用户提供个性化服务，但是单播传播方式却只能承载较小的流量；广播传播方式所需要的网络设备简单，对于信息的传输所需带宽较小，可以承受较大的流量，但是却无法为网络用户提供个性化服务，且较为容易耗尽带宽[2]。基于单播和广播的优缺点，设计组播系统既可以承受较大的流量，又可以为网络用户提供个性化服务。

目前，应用层组播系统设计已经成为互联网研究中的热点话题之一。国外早在20世纪末就提出Overcast，实现最大程度地扩宽接收者之间的带宽，并在此基础上提出Yatin cast系统，将应用层组播系统分为服务器和客户端两层结构。此后，国外众多学者不断研究出新型应用层组播系统，采用集中控制协议，减少应用层组播系统中各节点的汇聚时间，实现组播内容的转发[3]。相较国外而言，国内在21世纪初期才开始关于应用层组播系统的研究，主要采用覆盖网技术进行集中式控制，管理组播组。此后，国内学者在此基础上，提出了QoS控制机制，促使网络资源与用户设施配置之间达到最优[4]。文献[5]提出了调整并监控网络应用层组播系统网络中的节点动作，减少应用层组播系统在转发过程中存在的延时问题；文献[6]则提出了构建组播树，优化了组播系统网络中存在的延时问题，但对物理链路的利用率较低。针对上述组播系统设计中存在的不足，本文提出了基于拓扑感知的流媒体编码和应用层组播系统设计，降低组播系统求解时间，提高组播系统收敛速度。

1 流媒体编码和应用层组播系统硬件设计

此次设计的流媒体编码和应用层组播系统采用可以支持全双工线速的处理器，在该处理器上配置出口和入口，并在处理器芯片外部安装存储器和可编程只读存储器等，且采用交换器连接2个网桥，以Master模式启动，完成各硬件的启动过程。系统硬件的组成如图1所示。

图1 流媒体编码和应用层组播系统硬件组成

图1中，网络处理器是此次研究流媒体编码和应用层组播系统的核心部分，在系统中以实现组播路由功能为目的，主要负责对组播数据包的复制、转发。与网络处理器相连接的是2个SRAM外接存储设备和2个DRAM外接存储设备。这是因为SRAM外接存储设备在组播系统应用时，可以降低访问时间，适合存储需要多次访问的小型数结构据，用来存储组播系统常用数据包，如发送列队、包描述符、查找表等。但是由于SRAM外接存储设备造价高昂，且难以满足大型数据的接入需求，而DRAM外接存储设备造价便宜，可以存储不需要多次访问的大型数据结构。因此，DRAM外接存储设备被广泛使用于存储组播数据包和路由表。但是在对系统进行时间长的访问时，往往同时采用SRAM外接存储设备和DRAM外接存储设备，使其相互弥补缺点，并降低组播系统硬件的造价。在控制处理器与网络处理器之间，需要采用PCI总线进行连接，提高系统高层的控制和管理功能以满足组播系统的控制能力和运行。此次设计的流媒体编码和应用层组播系统硬件配置如表1所示。

表1 流媒体编码和应用层组播系统硬件配置

2 基于拓扑感知的流媒体编码和应用层组播系统软件设计

2.1 建立组播系统客户端

在此次研究设计的流媒体编码和应用层组播系统硬件基础上，完成流媒体编码和应用层组播系统客户端设计，将组播系统客户端分为数据采集模块、用户管理模块、流媒体数据处理模块等。

在组播系统客户端的数据采集模块中，主要是采集系统中，为方便下一模块，需要对用户发出的数据信息进行整理。此次设计组播系统客户端的信息采集模块是基于拓扑感知的特定网络软件探针节点，对组播系统中的信息进行感知及获取。由于拓扑感知的特定网络软件探针节点数量会影响拓扑感知对用户信息的获取[7]，所以将拓扑感知的特定网络软件探针节点布置成树形的拓扑结构。

由于此次设计的组播系统是由多个处理器和外接存储设备组成[8]，因此将拓扑感知的特定网络软件探针节点布置在多个处理器和外接存储设备上，完成多点数据采集。但是在采集组播系统时，拓扑感知的特定网络软件探针节点会存在静态和动态两种信息，而这两部分信息在运行过程中，静态数据信息产生的频率波动较小，动态信息产生的频率较大，且会产生周期性运作[9]。因此，拓扑感知的特定网络软件探针节点，需要针对这两部分信息，采用不同的采集频率。但是在采集动态数据信息时，动态信息所具有的周期性、频率高等特点，也会影响拓扑感知特定网络软件探针节点，在PCI总线上运行时，将给处理器增加负担，并在传递过程中，占用过多网络带宽[10]。所以在服务器上，将对拓扑感知的特定网络软件探针节点所采集到的用户数据信息进行初步处理，实现拓扑参数的初始化，从而完成用户数据信息的采集。

在上述用户信息采集模块下，采集到的用户数据信息会被拓扑感知的特定网络软件探针节点运输至流媒体数据处理模块，在流媒体编码的运行下，实现组播系统中的数据实时传输和同步，其数据运输处理流程如图2所示。

图2 数据运输处理流程

从图2可以看出，此次设计的组播系统客户端流媒体数据处理模块，是将网络当前数据节点与网络前数据节点建立网络连接，并通过该连接接收前节点的数据包；与此同时，当前节点还需要将接收到的数据包传递至动态循环缓冲区域；此时，子节点也会向当前节点发送连接请求，而当前节点会由数据包接收角色转变为数据包传输角色，将数据包传递至子节点。

由此可见，当前节点的任务繁重，既需要接收前节点的数据包，还需要将数据包传递至循环缓冲区域及子节点。因此需要根据当前节点位置，适当调整当前节点线程，保证组播系统客户端数据处理模块可以有效运转。此时组播系统客户端数据处理模块还会针对当前节点传递至缓冲区的数据进行读、写、调度等操作，降低数据发送的延迟时间，可以根据数据信息传递的方向，将缓存区的数据就近传递数据接收方。

此时可建立组播系统客户端的用户管理模块。在用户管理模块中，需要在服务器上设置维护用户列表，通过scratch-get（读取用户列表信息这段代码），可以读取用户管理模块用户列表信息；经过qm-cam-check[enqqueue-num，enq-hit#，qarray-entry]（检查用户列表信息是否正确），从而对列表信息进行更改，刷新用户管理模块列表；当有用户申请加入时，用户管理模块会产生qmset-deqhit-message[dequeuemessage-2]（加入用户列表代码），并对用户列表重新刷新；当有用户申请退出时，会产生qm-dequeue-ingress[dequeuemessage-0]（退出用户列表代码），对用户列表再次刷新[11]。此时，用户管理模块即可以在服务器上管理用户列表变化，检测用户的退出变化，及时更新用户列表信息。

2.2 确定组播系统协议内容

基于此次设立的数据运输处理流程，可以发现在数据传输过程中，总是以第一个运行的节点作为系统运行的启动节点。此时通过该节点可以向下一节点传输数据包，且一旦有其他节点的加入，必须向前一个节点传输连接请求，输入与启动节点相对应的IP和端口号[12]。因此可以以最先传递数据信息的节点创建一个组播组，此时的节点只有加入组播组，才可以正常接收数据包信息，并判断节点所加入的组播组是否正确，一旦发现节点所加入的组播组存在错误，会将节点及其传送的数据打包重新发回待加入节点。在组播组中有节点的加入就会有节点的退出，节点退出组播组，其一因为当前节点没有子节点，数据包不能向下一节点进行传递；其二，为保证子节点获取的数据包信息是有效信息，当前节点会主动退出组播组。

此时，新来的节点想要加入组播组时，会向组成组播组的根节点发送请求，根节点会根据新节点发送的连接信息判断新来的节点所携带的数据包是否属于自身所在的组播组，当判断结果表明，新来的节点属于组播组时，新节点会根据数据包信息寻找与自己信息相符的节点。其新节点加入组播组的过程如图3所示。

图3 新节点加入组播组过程

从图3新节点加入组播组过程可以看出，新来的节点N会先联系根节点RP，将自己的节点信息发送给根节点RP，根节点RP会获取组播组D1中存在的节点信息，并计算节点获取的优先顺序，则有：

式中：priority表示优先的；avaiBand表示可用的；reqBand表示待加入的；n表示所有节点，为自然数，即n=1,2,…,n。根据计算结果获取节点A，判断节点A与新来的节点N信息的相似度，当节点A的相似度和新来的节点N相似度较高时，根节点RP会将节点A的数据信息发送给新来的节点N，由新来的节点N排序节点A的逐跳延时，选取根节点挑选出的节点中，逐跳延时最小的节点，作为新来节点N的父节点[13]。此时的节点N既可以加入组播组，又可以将自身携带的数据包传递给组播组中的根节点RP。

上述过程为新来节点加入组播组过程，此时也会有组播组中的节点退出的过程。相对于新节点的加入，组播组中的节点退出相对要简单一些。根据前文提到的节点退出的两点原因，将没有子节点退出的节点设为J，此时的节点J会向组播组中的根节点RP发送退出信息。当根节点RP接收到节点J的信息后，会在组播组中寻找节点J的父节点，并将节点J退出信息传递给父节点，由父节点更新自身的子节点信息。然后将更新成功的信息发送给退出节点J，当节点J收到退出信息后，会再次向根节点RP发送退出信息，由根节点RP更新组播组，并通知节点J退出。其节点退出过程如图4所示。

图4 没有子节点的当前节点离开组播组过程

有子节点的退出节点H不存在父节点时，会直接向根节点RP发送退出信息，并更新自身节点存储的信息，从而确保自身下的子节点，在节点H退出后，可以重新加入组播组，并获取准确信息[14]。当根节点收到节点H的退出信息后，会恢复节点H，准许退出组播组的信息。然后由节点H通知，与自身具有直接关系的所有子节点离开，收到节点H的离开通知后，子节点会等待节点H退出。只有确定节点H退出后，子节点才会重新给根节点RP发送接入组播组信息，重复如图3所示的节点加入组播组的过程。其有子节点的退出节点H离开过程如图5所示。

图5 有子节点的当前节点离开组播组过程

此时的组播系统确定的协议内容在处理节点退出组播组时，根节点RP必须重新构建组播组信息，再将申请退出组播组节点删除，并根据新来节点信息再次更新组播组信息[15]。

综上所述，通过建立组播系统客户端，确定组播系统协议内容，通过节点的加入和退出，构建组播网，即组播组，以此来降低系统网络带宽延迟和损耗问题。至此完成组播系统软件设计。

3 实验论证分析

3.1 实验设计

为了测试此次设计的组播系统，在传输数据时不会对数据的质量产生影响，因此在局域网上测试系统。将局域网内的网络带宽定为10 MB/s，在系统内传输的数据都设置为Windows的.ASF文件格式，并将数据包定为1 s的数据，其数据缓冲区BM采用循环列队进行记录，将其大小定为120 bit，网络中的节点生存时间设定为3 s。

3.2 流媒体编码和应用层组播系统数据传递到达速率测试实验

在此次实验设计的基础上，将此次测试的组播系统作为A系统，引言里提到的两种组播系统分别作为B系统和C系统，将目前系统传递数据速率作为实验对照组。此时，将系统的传递初始速率定为60 Kb/s，在系统数据传递50 s后，将系统传递数据的速率调整为80 Kb/s，系统数据传递100 s后，系统传递数据的速率，调整为100 Kb/s；最后在系统数据传递150 s时，将系统传递数据的速率，重新调整回80 Kb/s。此时对比系统节点对数据包的传递速率，其对比结果如图6所示。

从图6可以看出，B系统的节点，在传递数据包时，虽然在调整数据传递速率时，节点跟随速率的变化在相应的调整时间的过程中会出现丢包现象，但产生的数据传递速率波动频率剧烈；C系统的节点，在传递数据包时，与对照组产生的数据传递速率完全不一致，且在速率传递过程中会自行调整，产生严重的数据包丢失现象；而A系统与对照组传递速率完全一致。综上所述，此次设计的组播系统，数据传递速率快且稳，且在传递过程中，带宽资源充裕。

图6 节点接收数据包速率对比图

3.3 不同文件大小下系统传输效率测试实验

在第3.1节设计试验，第3.2节实验测试下，为保证此次系统设计的严谨性，设计第2组实验，对比不同文件大小下系统传输效率。此次实验测试，依然采用第3.2节实验选取的两个系统，作为此次实验的对比组。在此次实验中，将文件大小分别设为51 MB，129 MB，212 MB和407 MB，每个系统都选取A，B，C，D，E五个节点，记录每个节点对数据传输的时间，从而对比3组系统的文件传输效率，其实验结果如表2所示。

表2 不同文件大小下3组系统的传输效率

针对表2记录的3组系统传输效率进行统计，以便对3组系统传输效率进行对比分析，其统计结果如表3所示。

表3 三组系统传输效率对比结果

从表3中可以看出，此次设计系统，在数据传输的整体上看，传输时间少于B系统和C系统，则传输效率高，数据传输快。由此可见，此次设计的组播系统提高了数据传递效率。

4 结 语

此次设计的流媒体编码和应用层组播系统，充分发挥出拓扑感知技术对数据的感知能力，增加流媒体编码和应用层组播系统对用户数据的管理能力。但设计系统对拓扑感知技术理解不够深入，没有全面考虑网络用户对组播系统的需求，未能实现组播系统的视频播放功能。因此在今后的研究中，需要对拓扑感知技术进行深入分析，考虑更多的数据管理方式，为系统程序打好基础。