可靠IP组播通信中间件研究与实现

李磊 陈静

郑州大学信息工程学院 河南 450001

0 引言

目前，多数商品期货交易所的行情发布主要使用TCP/IP进行可靠数据的传输。TCP通信需要建立端对端的连接，在行情发布中，传输的数据大部分是重复的，这些重复传输的数据连接占用大量网络带宽，随着交易规模扩大，就会出现网络容量上的瓶颈。

IP组播提供一对多和多对多的数据通信，可以减少网络中重复数据传输个数。基于UDP协议的IP组播进行数据传输是不可靠的，针对这个问题，研究并设计了基于IP组播的可靠组播通信中间件。

1 可靠组播技术概述

可靠组播技术是基于IP组播的基础之上，加上报文的差错检测和差错恢复机制，保证了数据传输的可靠。

1.1 IP组播的特点

IP组播是基于UDP协议，使用D类地址，把数据分组发给网络中的一组主机。它具有以下几个特点：

(1) 尽力传递，不保证接收。

(2) 无安全机制，任何主机都可以加入组播组中。

(3) 不提供拥塞控制和流量控制。

(4) 一次发送，多次接收。

虽然IP组播存在着一定的问题，但 “一次发送，多次接收”的网络数据传输效率，加上由此引伸出的网络的可伸缩性的优点，是单播中无法企及的。如果对IP组播技术进行可靠性的改进，组播技术在实际应用中有着广泛的空间。

1.2 IP可靠组播关键技术

虽然IP组播存在着一些弱点，但在其基础上加上差错恢复技术和拥塞控制机制及其他安全手段，可以保证数据在传输过程中的可靠性和稳定性，以在实际应用中使用。可靠组播可以用下式表示：

可靠组播=IP组播+[差错检测恢复]+[拥塞控制]

2 可靠组播通信中间件协议设计

2.1 可靠组播通信中间件的特性

本文可靠组播通信中间件是面向中小型交易的，它在实际应用做作为行情发布的通信支持。因此，它是一个针对性比较强的组播通信中间件。具体表现为以下特征：

(1) 平面组织结构：平面组织结构和层次性组织结构相比，通信的规模比较小，但是报文的传送速度比较快，报文可以直接到达。它是基于实际中要求通信规模不大，但是实时性能要求很高的特点进行设计的。

(2) 报文拆分合并功能：在数据传输的过程中，由于来自应用程序的单个数据可能超过UDP报文的最大荷载长度，因此为了保证数据能够完整的传输，需要对其进行拆分，与此同时，在接收端提供对拆分过的数据进行合并的功能。

(3) 可选的小报文的合并功能：为了提高组播的传输效率，提高网络链路的利用率，提供了对小报文的可选合并功能，当网络不好而接收方和发送方有比较充裕的时间，则可以开启此功能，提高传输效率。此功能属于可选项，在实际应用中可以选择是否开启。

(4) 单可靠组播通道，多地址传送：为了满足正常数据报文和重传数据报文的合理传输，并能够支持发送端和接收端的双向通信功能，将其多播传送地址分开，有专门负责正常数据传送和重传报文的发送地址。

(5) 单播组播可选恢复机制：对于错误报文的发现和恢复的情况，都分别提供了单播和组播的功能实现，上层应用可以根据对于错误报文的需要进行合理选择。在默认使用组播的情况下，协议采用组播完成错误报文的恢复机制。

2.2 协议报文设计

协议数据报文的设计分为两类：可靠组播中的UDP报文和可靠组播数据报文。

(1) UDP报文：它由UDP报文头和可靠组播数据报文组成。可靠组播数据报文填充UDP报文，根据填充规则，可以是一个可靠组播数据报文也可以是多个可靠组播数据包。如图1所示。

图1 包含多个组播报文的UDP包结构

(2) 可靠组播数据报文：它是由可靠组播报文头和可靠组播数据组成。可靠组播报文头是可靠组播设计的重点，它需要满足不同要求的数据传输，并要求对报文进行快速处理，因此报文头部分采取定长，并提供报文类型、服务质量、优先级、是否数据进行拆分等信息。可靠组播报文头部结构如图2所示。

(3) 主要报文类型：在可靠组播中，提供了数据报文和控制报文。主要的数据报文为正常数据报文，重同步请求报文，重同步数据报文，心跳数据报文，重开始发送报文等，并对同等条件下的报文提供不同的优先级。

2.3 关键技术

可靠组播通信中间件的设计中，为了保证数据的可靠传输，也必须用合理的差错恢复和拥塞控制的方法。

(1) 差错恢复和差错检测的处理方法

采用基于NACK的方式来进行差错检测和恢复。数据接收端利用协议中设计的序列号字段检测，当收到的序列号不是期待的，可以认为数据丢失。由于在传输过程中，有可能并不是一个接收端丢失数据，因此接收端等待一定的时间间隔，才向发送端请求数据重传。

为保证传送的效率，发送端对发送数据进行缓冲管理，当有数据重传请求时，可以快速给出响应。

(2) 拥塞控制的处理方法

在传输过程中，采用基于速率的拥塞控制方法，采用的拥塞控制方式为LHR。当有NACK到达发收端时，降低发送速率，当没有收到NACK时，增加发送速率，从而保证了能够及时处理大量的数据。

为保证数据的平滑发送，提供最大和最小的发送速率，在最大最小发送速率中提供若干个速度等级用于调节发送速率平衡，从而很好的控制传输速率，不让网络发生剧烈“抖动”。

3 可靠组播通信中间件的实现

3.1 实现框架

本文可靠组播协议最终的实现是以逻辑流为基本通信单位的通信中间件。在一个逻辑流中，数据发送端和数据接收端按照可靠组播协议进行通信，为了保证通信的实时性和数据处理的快速行，对数据发送、恢复、合并、拆分等过程采用多线程的机制进行协调处理。

对于一个逻辑流，按照任务的不同，分为数据接收端和数据发送端。其中数据发送端在一个逻辑流中有且只有一个，数据接收端可以是多个。数据发送端作为数据的输出端，接收端即为一个数据的出口，它把数据给应用程序使用。一个完整的逻辑流包括发送端和接收端，以及协调发送和接收端的一些公共模块，根据可靠组播协议的设计，实现一个逻辑流的结构如图3所示。

图3 逻辑流的层次结构

在一个逻辑流中，最重要的部分为逻辑流的发送端和接收端，下面分别对发送端和接收端的实现进行描述。

3.2 数据发送端

发送端借助于计时器，对上层应用的数据进行拆分/合并，并对发送的数据进行缓存，同时监听重传请求，对请求进行响应。它包括以下数据结构和线程：

(1) 主要数据结构

① 上层应用数据队列：当应用程序调用发送数据的函数接口时，即把应用程序的数据放到应用数据队列中。该队列使用一个链表结构来管理这些大小不一的数据。

② 数据发送队列：经过发送端的数据处理线程处理以后，把数据进行拆分或者合并，把数据整理成可以直接发送的数据包，放入到发送队列中。发送队列可以被发送线程直接发送。

③ 已发送数据的缓存队列：对于已发送的数据，按照设置进行存储，用于数据重同步时使用。这里需要注意的是，并不是对所有的数据都进行存储，而是根据缓冲区大小参数设置，当缓冲区超过此参数时，就把最早进入该队列的数据进行删除，添加新的数据节点。

④ 重传请求队列：当重传监听线程监听到重传请求时，把重传请求放入重传请求队列。

(2) 主要线程

① 发送数据处理线程：对上层应用程序进行合并、拆分处理，并且添加相应的可靠组播头，组装成待发送数据，填充到可靠组播的数据发送队列里。

② 发送线程：对数据发送队列进行发送，同时把已发送的数据缓存到已发送数据的缓存队列中。

③ 监听重同步线程：当监听线程监听到重同步请求时，为了继续监听数据，此时需要把监听的数据存储到重同步请求队列。

④ 重同步处理线程：对重同步请求队列中的数据进行处理，它从已发送缓存中查找数据，根据查找结果，进行重同步的恢复或者其他处理。

数据发送端主要处理两个主要工作：数据发送和数据恢复与重传。它俩紧密联系，并且提供数据的流量控制。流量控制部分主要放在监听重同步线程中实现，它的实现方法如下：数据的发送提供不同的速率，监听重同步线程发现有数据丢失情况，则降低发送速率，没有重传请求时，增大发送速率，从而达到数据的平稳传输。

3.3 数据接收端

数据接收端负责接收并分析数据，提供差错检测功能，同时对数据合并或者拆分，提交到上层应用程序。它主要包括以下数据结构和线程：

(1) 主要数据结构

① 接收数据队列：用于缓存接收到的数据包。它由数据接收线程接收，数据处理线程进行处理。

② 应用数据队列：接收端数据处理线程对接收到的数据包进行处理，并对处理过的数据进行缓存，这个缓存队列就是应用数据队列，它是提交给应用程序的数据队列。

③ 重同步请求队列：当检查到序列号丢失时，则发送数据差错的恢复请求，即数据的重同步请求，该请求的报文被放入到重同步请求队列，由重同步请求线程进行处理。

(2) 主要线程

① 数据接收线程：负责接收数据，并对不同类型的报文做出不同的处理。对数据报文，放入到接收数据队列。并负责检测报文是否丢失。

② 数据处理线程：对接收的数据队列中的数据进行分析，并根据需要对数据进行合并或者拆分操作，对处理过的数据放入到应用数据队列。

③ 重同步请求线程：对丢失的报文进行重同步请求，它对重同步请求队列扫描，当有重同步请求时，发送重同步请求。

在一次接收过程中，接收部分的各个模块之间进行的协调关系，如图4所示。

图4 接收端接收数据的处理过程

4 性能测试结果

对网络协议的测试，目前主要的测试方法包括实际测量，网络模拟和数学分析等，每个测试的侧重点都不尽相同。针对可靠组播通信中间件在实际中使用的情况，主要采用实际测量的方法测试。

4.1 测试方法及环境

4.1.1 测试方法

这里仅对组播测试进行吞吐量的测试，在这个过程中，采用了实际的数据与理论上的吞吐量进行对比。

理论上的吞吐量用总的数据除以数据发送的时间，即得到理论上的吞吐量。

实际的吞吐量采用实际中的参数进行测试，假设每个发送周期都能将发送窗口大小数量的报文发送出去，并且接收端都正确收到，在没有数据重传的情况下，利用发送时延计算出每秒钟发送次数，然后同每次发送的数据量作乘法运算，得出系统的吞吐量，可以通过对其进行设置以调节发送端吞吐量。计算公式为：

公式中各参数的意义为：

Throughput(bps)—— 代表发送端的吞吐量；

PacketSize——代表每个数据包最大数据载荷，内部参数；

Windowsize—— 代表发送窗口大小，即每次发送数据包个数，内部参数；

Timedelay——代表发送时延，以毫秒作为计时单位，内部参数。

上述计算方法是理想状态下对吞吐量的计算，并未考虑报文丢失，但在实际情况中，系统中会出现不定量的丢包情况。因此，上述方法不能精确反映系统的性能，随着丢包率的增大，实际的吞吐量将会与计算结果相差越来越大，理想状态下的吞吐量计算值只能作为参考值，反映吞吐量的上界。

4.1.2 测试环境

实验在没有他人使用的网络的情况下进行，网络环境为带宽为100Mbps的局域网。发送主机和4台接收主机均采用使用的是Redhat Linux操作系统，机器配置均为512M内存，2.8GHz奔腾CPU。

4.2 测试结果及分析

在多种配置下组播传输一个2M字节大小的数据块，其性能，参数，实验吞吐量，理论吞吐量如表1所示。

表1 实验数据对比表

实验结果表明，在该组数据中，观察到的实验数据与预期数据比较吻合，一般情况下对协议参数设置在合理范围内均能达到较好的运行效果。

5 结束语

本文在分析IP组播的基础上，研究了可靠组播的特点，并结合实际，完成可靠组播通信组件的设计。目前可靠组播通信组件已在行情发布中投入使用，运行稳定。下一步将进行可靠组播通用性的研究，使其能够应用于多种应用场景。

[1] RFC2357： IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols. 1998.

[2] Juan-Mariano de Goyeneche. Multicast over TCP/IP HowTo[M].v1.0. March 1998.

[3] J.Widmer, R.Denda, and M.Mauve. A Survey on TCP-Friendly Congestion Control. IEEE NetWork, May/June 2001.

[4] 徐恪,吴建平,徐明伟.高等计算机网络.机械工业出版社.2003.