一种针对数据分发服务的传输性能评估数据的获取方法

摘要

本发明涉及一种针对数据分发服务的传输性能评估数据的获取方法，属于通信传输领域。该方法执行如下步骤：步骤1，关联匹配；步骤2，数据传输；步骤3，获取传输性能评估参数。本发明在数据分发服务的场景下，实现了低运行开销、低网络开销、实时性、全面覆盖和低复杂度的数据传输性能评估获取方法。在数据分发服务的标准化互操作协议RTPS（实时发布‑订阅协议）的基础上，选择其所属的十二种不同子消息中的若干子消息进行修改。在不改变原协议规范的基础上，实现其数据交互流程，同时在收发端可以获取与传输性能相关的数据。

权利要求

1.一种针对数据分发服务的传输性能评估数据的获取方法，其特征在于，执行如下步骤：

步骤1，关联匹配；

所述数据分发服务涉及的各应用中的发布者和订阅者通过主题进行匹配；

步骤2，数据传输；

基于RTPS消息及RTPS协议标准通过单次数据从发布者传输到订阅者和/或发布者传输到订阅再由订阅者返回发布者的过程来获取所述发布者到所述订阅者的单次数据传输的传输性能评估参数；

所述RTPS消息包括数据子消息、心跳子消息、确认子消息和时间戳子消息；

其中，所述数据传输中报文的所述确认子消息前有携带至少一个时间戳的所述时间戳子消息；

步骤3，获取传输性能评估参数；

从所述发布者和/或订阅者中获取所述传输性能评估参数；

所述传输性能评估参数包括单向时延、往返时延、抖动、报文数和吞吐量；

步骤4，各应用将传输性能评估参数汇总于各自的分机，所述分机将数据上传主机，实现所述数据分发服务整体的传输性能评估参数汇总。

2.根据权利要求1所述的针对数据分发服务的传输性能评估数据的获取方法，其特征在于：所述应用中包括至少一个发布者和/或至少一个订阅者。

3.根据权利要求2所述的针对数据分发服务的传输性能评估数据的获取方法，其特征在于：所述发布者包括至少一个数据发送器，所述订阅者包括至少一个数据阅读器。

4.根据权利要求3所述的针对数据分发服务的传输性能评估数据的获取方法，其特征在于：步骤1中的发布者和订阅者通过主题进行匹配是指，所述发布者中一个数据发送器与所述订阅者中的至少一个数据阅读器关联同一个主题。

5.根据权利要求1所述的针对数据分发服务的传输性能评估数据的获取方法，其特征在于：步骤2中，所述时间戳子消息所携带时间戳数量为三个，分别为所述发布者发出所述单次数据时所对应的时间戳、所述订阅者收到所述单次数据时所对应的时间戳、所述订阅者回复所述单次数据时所对应的时间戳，并依照时间先后顺序排序。

说明书

一种针对数据分发服务的传输性能评估数据的获取方法

技术领域

[0001] 本发明涉及一种针对数据分发服务的传输性能评估数据的获取方法，属于通信传输领域。

背景技术

[0002] DDS的全称是Data Distribution Service，即数据分发服务，是对象管理组织(OMG)在HLA及CORBA等标准的基础上制定的新一代分布式实时通信中间件技术规范。该规
范标准化了分布式实时系统中数据发布、传递和接收的接口和行为，定义了以数据为中心
的发布‑订阅(Data‑CentricPublish‑Subscribe)机制，提供了一个与平台无关的数据模
型。DDS将分布式网络中传输的数据定义为主题(Topic)，将数据的产生和接收对象分别定
义为发布者(Publisher)和订阅者(Subscriber)，从而构成数据的发布/订阅传输模型，如
图1所示，为一个典型的数据分发服务的数据交互模型。各个节点在逻辑上无主从关系，点
与点之间都是对等关系，通信方式可以是点对点、点对多、多对多等，在QoS的控制下建立连
接，自动发现和配置网络参数。

[0003] 由于DDS不具备底层的网络层权限，需与基础网络（如UDP/IP）提供的内容兼容，不能保证确定性行为。所以为了满足实时性和时间确定性的需求，DDS与时间敏感型网络
（TSN）的结合是未来工业通信系统设计发展的方向和趋势。

[0004] 同时，为了评估端到端的实时性和确定性，也需要相应的数据传输性能评估机制，即从当前数据分发服务中取得评估用参数的方式方法，并以此得到或作为评估当前网络性
能状况的依据。在过去，对于此项需求所使用的方式是借助NQA的网络性能度量与诊断工
具。NQA通过主动在多个站点之间或多条路径之间发送指定数量的报文，来获取可以度量网
络性能的数据，以便得到如丢包、抖动、IP地址的时延、TCP连接时延、HTTP总时延、FTP连接
时延和文件传输速率等。用户通过专门的命令行或网管配置NQA测试用例，以指定对应的协
议类型、报文长度、发包间隔、TOS标记等参数。根据测试结果，用户可以了解到当前网络的
性能状况，以做出适应性调整。

[0005] 尽管NQA能够满足目前对于端到端的实时性确定性评估的需要，但NQA的运行机制需要在网络两端分别部署server端和client端。且评估过程会占用额外的网络开销和性能
开销。不能够适应数据分发服务的场景特性，降低了分发服务部署的灵活性。因此需要一种
新的方式，既可以获得数据传输性能参数作为评估依据，又可以适应目前数据分发服务的
特有需求。

发明内容

[0006] 本发明要解决的技术问题是：提供一种基于DDS的数据传输性能评估机制，且满足性能评估对于实时性和准确性的要求。

[0007] 为了解决上述技术问题，本发明提出的技术方案是：一种针对数据分发服务的传输性能评估数据的获取方法，执行如下步骤：

[0008] 步骤1，关联匹配；

[0009] 所述数据分发服务涉及的各应用中的发布者和订阅者通过主题进行匹配；

[0010] 步骤2，数据传输；

[0011] 基于RTPS消息及RTPS协议标准获取所述发布者到所述订阅者的单次数据传输的传输性能评估参数；

[0012] 所述RTPS消息包括数据子消息、心跳子消息、确认子消息和时间戳子消息；

[0013] 其中，所述数据传输中报文的所述确认子消息前有携带至少一个时间戳的所述时间戳子消息；

[0014] 步骤3，获取传输性能评估参数；

[0015] 从所述发布者和/或订阅者中获取所述传输性能评估参数；

[0016] 所述传输性能评估参数包括单向时延、往返时延、抖动、报文数和吞吐量。

[0017] 上述方案的进一步改进是：步骤4，各应用将传输性能评估参数汇总于各自的分机，所述分机将数据上传主机，实现所述数据分发服务整体的传输性能评估参数汇总。

[0018] 上述方案的进一步改进是：所述应用中包括至少一个发布者和/或至少一个订阅者。

[0019] 上述方案的进一步改进是：所述发布者包括至少一个数据发送器，所述订阅者包括至少一个数据阅读器。

[0020] 上述方案的进一步改进是：步骤1中的发布者和订阅者通过主题进行匹配是指，所述发布者中一个数据发送器与所述订阅者中的至少一个数据阅读器关联同一个主题。

[0021] 上述方案的进一步改进是：步骤2中，所述时间戳子消息所携带时间戳数量为三个，并依照时间先后顺序排序。

[0022] 本发明的有益效果是：本发明在数据分发服务的场景下，实现了低运行开销、低网络开销、实时性、全面覆盖和低复杂度的数据传输性能评估获取方法。在数据分发服务的标
准化互操作协议RTPS（实时发布‑订阅协议）的基础上，选择其所属的十二种不同子消息中
的若干子消息进行修改。在不改变原协议规范的基础上，实现其数据交互流程，同时在收发
端可以获取与传输性能相关的数据。

[0023] 实现了复用RTPS协议的处理流程；复用RTPS协议报文，仅在报文内部新增有限的子消息；在数据报文和协议报文交互的同时即完成网络传输性能的评估；得益于实时发布/
订阅协议的特性，评估机制可以覆盖每一个发布/订阅者和数据发送器/数据阅读器；仅对
RTPS协议的处理流程做小幅改动，无需引入复杂的检测协议。

附图说明

[0024] 图1是本发明中的典型的数据分发服务的数据交互模型。

[0025] 图2是符合RTPS规范的一次数据消息的交互流程图。

[0026] 图3是本发明实施例一的流程示意图。

[0027] 图4是本发明实施例一中获取单向时延的流程示意图。

[0028] 图5是本发明实施例一中获取往返时延的流程示意图。

[0029] 图6是本发明实施例一中数据汇总的模型示意图。

[0030] 图7是本发明实施例二考虑多种因素影响后的获取往返时延的流程示意图。

具体实施方式

[0031] 实施例一

[0032] 本实施例的一种针对数据分发服务的传输性能评估数据的获取方法，如图3所示，执行如下步骤：

[0033] 步骤1，关联匹配；

[0034] 数据分发服务涉及的各应用中的发布者和订阅者通过主题进行匹配；

[0035] 步骤2，数据传输；

[0036] 基于RTPS消息及RTPS协议标准获取发布者到订阅者的单次数据传输的传输性能评估参数；

[0037] RTPS消息包括数据子消息、心跳子消息、确认子消息和时间戳子消息；

[0038] 其中，数据传输中报文的确认子消息前有携带至少一个时间戳的时间戳子消息；

[0039] 步骤3，获取传输性能评估参数；

[0040] 从发布者和/或订阅者中获取传输性能评估参数；

[0041] 传输性能评估参数包括单向时延、往返时延、抖动、报文数和吞吐量。

[0042] 以图1的典型的数据分发服务的数据交互模型为例，该模型中有3个应用（application），application1、application2、application3。其中，application1有1个发
布者（publisher）和1个订阅者（subscriber），application2有一个订阅者，application3
有一个发布者。每一个发布者都有至少一个数据发送器（data writer），每一个订阅者都有
至少一个数据阅读器（data reader）。可以看到，application1的发布者有两个数据发送
器，application2的订阅者有两个数据阅读器。每个数据发送器与数据阅读器通过主题
（topic）关联匹配，从而实现发布者与订阅者的匹配。

[0043] 本实施例中，当已建立关联匹配的数据发送器与数据阅读器之间传输数据时，基于RTPS协议实现。按照RTPS标准实现一次数据消息的交互流程如图2所示。

[0044] RTPS消息由标题和几个子消息组成。RTPS规范中定义了十二种不同类型的子消息。本实施例涉及到四种类型的子消息，分别为数据子消息（DATA）、心跳子消息
(HEARTBEAT)、确认子消息（ACK/NACK）和时间戳子消息(InfoTimestamp)。

[0045] 本实施例的单向时延，首先需借助精确时钟同步协议，比如，PTP或其他类似，以实现高精度时钟同步。在此基础上，如图4所示，数据发送器于T1时刻发出一条携带有时间戳
（T1）、数据和心跳的消息。而数据阅读器在于T2时刻收到，则从数据发送器到数据阅读器的
单向时延为T2‑T1。与之类似，数据阅读器于T3时刻回复一条携带有时间戳（T3）和确认的消
息，数据发送器于T4时刻收到并计算出由数据阅读器到数据发送器的单向时延为T4‑T3。

[0046] 本实施例的往返时延，如图5所示，数据发送器于T1时刻发出一条携带有时间戳（T1）、数据和心跳的消息。数据阅读器收到后，记录下T1，并立刻回复一条携带有时间戳
（T1）和确认的消息，数据发送器于T4时刻收到并计算出数据发送器和数据阅读器之间的往
返时延为T4‑T1。

[0047] 本实施例的抖动，取决于以本实施例中方法获取的单向时延/往返时延，在其前后几次数据传输过程中的差值。

[0048] 本实施例的报文数、吞吐量，在数据阅读器中分别维护一个数据报文数量计数和数据报文有效总长度计数。每当数据阅读器收到来自数据发送器的数据消息，即对这两个
计数进行维护。当前消息中的数据报文长度可以从RTPS协议处理层获取。通过周期性计算
可以得到报文速率（pps）和吞吐量。

[0049] 此外，实际应用中，应用中的数据发送器会根据主题关联匹配多个数据阅读器，某个数据发送器到数据阅读器的评估数据并不能表现出整体的性能和情况。且一部分的性能
评估是在数据发送器上完成，如数据阅读器到数据发送器的单向时延、数据发送器和数据
阅读器之间的往返时延；另一部分 则是在数据阅读器上完成，如数据发送器到数据阅读器
的单向时延、报文数量、吞吐量。因此，实际使用中，为了获得整个数据分发服务的部署情
况，如图6所示，在模型中的每一个应用中设置诊断用的client端，无论是数据发送器或数
据阅读器的数据都将先到client端，再汇总到server端，从而获得对于数据分发服务的部
署情况的整体评估数据。

[0050] 本实施例的应用中包括至少一个发布者和/或至少一个订阅者。

[0051] 实施例二

[0052] 本实施例与实施例一基本相同，不同之处在于，本实施例的往返时延较于实施例一更为精确，考虑了性能、调度等因素对于时延的影响。如图7所示，数据发送器于T1时刻发
出一条携带有时间戳（T1）、数据和心跳的消息。数据阅读器于T2时刻收到，并记录下T1和
T2。数据阅读器于T3时刻回复一条携带有时间戳（T1，T2，T3）和确认的消息，数据发送器于
T4时刻收到并计算出数据发送器和数据阅读器之间的往返时延是T4‑T1‑（T3‑T2）。即排除
由于各种原因导致的，数据阅读器的发送非即时产生造成的时延，以展现出与外因无关，完
全基于数据分发服务的部署情况相关的往返时延，以便提供参考依据。

[0053] 本发明不局限于上述实施例所述的具体技术方案，除上述实施例外，本发明还可以有其他实施方式。对于本领域的技术人员来说，凡在本发明的精神和原则之内，所作的任
何修改、等同替换、改进等形成的技术方案，均应包含在本发明的保护范围之内。