CN1649344A - 一种在因特网上实现交互式多媒体数据传输的方法 - Google Patents

Abstract

在因特网上实现交互式多媒体数据传输的方法属于多媒体网络技术领域，其特征在于：它依次含有新用户按照自组织步骤连接到树型结构中的步骤；按照数据路由步骤进行高效、可靠的多媒体数据的发送接收的步骤；用户退出应用时，按照自修复步骤退出树型结构，再将树型结构做相应动态调整的步骤。在数据传输上它具有：传输高效可靠、路由简单高效、保证数据的全局有序性、对出现差错的数据可有效进行差错修复、对链路拥塞能有效进行流量控制以及在出现故障、链路断路、用户退出时可实现树型结构自修复的优点。

Description

一种在因特网上实现交互式多媒体数据传输的方法

技术领域

本发明属于多媒体网络技术领域，特别涉及交互式多媒体数据传输的方法。

背景技术

随着网络和多媒体技术的飞速发展，出现了很多交互式多媒体应用，如远程会议系统、远程教学系统以及网络游戏等等。从而会有各种类型的多媒体数据在网络上进行交互传输。但现有的网络是一个很复杂的状况，用户既可以是通过拨号上网，也可以是通过局域网接入网络。这样一来，用户接入的带宽差异就很大，像拨号上网只有56K的带宽，而通过局域网接入则可以有10M、100M或更多的带宽。而且，用户终端的性能也会有很大区别，用户可以是高性能工作站，也可以是处理能力、屏幕大小、内存大小都很有限的手持或嵌入式设备。当拥有不同接入带宽和处理能力的终端同时参加一个会话时，如何满足他们的要求是一个十分困难的问题。如果为了迁就低端用户就给所有用户发送低品质的数据，高端用户的带宽和处理能力就白白浪费了，而发送高品质的数据又会让低速网络和终端无法承受，因此，必须设计一种方法，让不同能力的用户享受不同品质的数据。

为此，我们提出了一种的在因特网上实现交互式多媒体数据传输的方法。该方法可以很好的解决上述问题。这种方法基本的工作原理是，首先将参与到这个交互式多媒体应用的所有用户终端按我们方法中自组织的步骤组织成一个树型结构；进而，多媒体数据基于这个树型结构会按方法中的路由步骤进行交互传输；当数据在传输过程中发生错误时，会按照方法中的差错修复步骤保证其正确性；同时，由于网络状况的动态性，多媒体数据的传输速度有可能会受到影响，通过我们方法中的流量控制和拥塞控制步骤可以实时对数据的传输进行调控；在交互式多媒体应用中，保证所有用户终端看到数据显示顺序的一致性是很重要的，也就是不应当出现在一个用户终端看到的是A事件在B事件之前发生，而另一个用户终端却看到B事件发生在A事件之前。按照我们方法中的保证全局有序步骤就可以很好的解决这个问题；当网络中出现某段链路故障，或者树型结构中的某个用户终端出现异常，导致树型结构需要调整的时候，可按照方法中的自修复步骤实时的优化树型结构，保证多媒体数据高效可靠的进行交互传输。

由于越来越多的交互式多媒体应用出现，产生了很多对于多媒体数据的传输方法。Lawrence Berkeley Laboratory提出的可靠数据传输方法SRM(Scalable ReliableMulticast)，在白板应用及其改进版本MediaBoard中实现。SRM基于的思想是，满足应用需求最好的方式是把尽可能多的功能和灵活性交给应用，把应用程序的语义明确地包含在协议的设计中。在SRM中，传输层和应用层没有明显的界限，二者使用同一个数据结构，传输层直接使用应用层的命名模型进行数据传输和差错恢复。这样做的好处是传输协议是根据应用的要求定制的，提高了效率，缺点是协议过于依赖应用层的语义，缺乏通用性。

而且，SRM本身没有包含任何并发控制机制，并发控制在白板应用中实现。操作的执行顺序由每个操作时间戳决定，时间戳直接取自本地时钟，而白板应用假设每个成员的时钟都用外部协议如NTP(Network Time Protocol)同步。由于分布式系统中任何一个进程都不可能取得准确的物理时间，而NTP(Network Time Protocol)的精度只有几十个毫秒，因此很有可能后发生的操作取得一个较小的时间戳而先执行，从而破坏了因果关系。正确的并发控制算法应该使用逻辑时间而不是物理时间。

SRM的另外一个问题是可伸缩性。其差错恢复算法要求测量到每个成员的距离，用RTT(Round Trip Time)值度量，RTT为每两个成员之间所用时间。而会话消息包含测量所需的每个成员的时间戳，其大小和成员数量成正比。为了减少带宽占用就必须降低会话消息的发送频率，由于RTT值总是不断变化的，过低的测量频率使测量失去意义。

因此，目前存在的现有交互式多媒体传输方法，在健壮性、可靠性以及扩展性方面不是很令人满意，不能满足市场上交互式多媒体应用的需求。

发明内容

本发明针对现有技术的不足之处，提出了一种传输交互式多媒体数据的方法。它具有高效、灵活、可靠的特点。支持在各种网络带宽条件下进行交互式多媒体数据的传输。有很好的发展前景。

本发明方法是基于对等实体模型的。所谓对等实体模型是指参与传输的各节点在传输过程中的地位是平等的，不存在服务与被服务的关系。

本发明的特征在于：

首先在进行交互式多媒体数据传输的各台主机上设定：

参与传输的各节点即用户在传输过程中的地位是平等的；

对数据段采用的是层次数据结构模型的数据命名方式，每一个数据段是由下述四个元素组成的四元组来确定该数据段的空间位置的；

频道标识：每个频道有一个在会话中唯一的频道标识；

流标识：每个数据流都有一个在频道中唯一的流标识，它是一个随机产生的32位整数；

消息序号：每个消息都有一个在数据流中唯一的消息序列号，所述消息是指数据流中一个对上层应用有意义的数据单元，所述序列号是一个单调递增的整数，由发送者确定；

段位置序号：每个数据段用它在消息中的位置序号作为标识；

用一个树型结构的各节点来表示参与到这个交互式多媒体应用的所有用户终端，顶级用户的IP地址和监听端口是给定的；且一个用户直接单播连接的下级用户数目的最大值也是给定的；

在树型结构中的顶级用户内建立“所有用户信息”数组，其数据项会有每个用户的IP地址、每个用户的直接上级用户的IP地址和是否是公网IP的标识；

在树型结构中的每个要加入多媒体应用的新用户内建立“备选上级用户”链表，其数据项含有：备选上级用户的IP地址、新用户通过该备选上级用户直接达到顶级用户的时间，即RTT值、以及该备选上级用户的直接下级用户是否被测试过的标识；同时，还要建立一个发送服务成功数据包用的“本用户信息”数据组，其数据项含有提供服务用户的IP地址、新用户的IP地址以及和提供服务的用户是否在同一多播域内的标识；另外，还有一个由新用户向顶级用户发送RTT测试包用的数据组，其数据项为：新用户发送RTT测试包的时间、接收RTT测试包的用户到顶级用户的RTT值以及和接收RTT测试包的用户直接单播连接的用户数目是否已达到最大值的标识；

接着，本发明将依次按下述步骤进行：

步骤1：一个新用户按照下述自组织的步骤连接到上述树型结构中来参与多媒体应用；

步骤1.1：新用户询问顶级用户自己参与的多媒体应用的多播地址和多播端口；

步骤1.2：新用户向多播地址和端口发送服务请求，来得知该多播域内是否已经存在有加入此多媒体应用的用户；

步骤1.3：如果收到应答，即表明本多播域内已经有加入此应用的用户，则新用户选择给予它应答的用户作为其上级用户，并发送发现服务成功数据包给这个上级用户和顶级用户，顶级用户把新用户信息记录到“所有用户信息”数组中；

步骤1.4：如果新用户在一段时间内没有收到对步骤1.2中发送的服务请求的响应，便依次执行以下步骤：

步骤1.4.1：新用户把顶级用户加入到自己的“备选上级用户”链表中，并向顶级用户发送RTT测试包，顶级用户便把自己连接的单播用户数目是否达到最大值的标识填充到RTT测试包中，然后将这个RTT测试包返回给新用户；

步骤1.4.2：新用户便对顶级用户发来的RTT测试包进行下述判断：与顶级用户直接连接的单播用户数目是否已经达到最大值；

步骤1.4.3：若未达到最大值，便把顶级用户作为其上级用户，并发送发现服务成功数据包给顶级用户，顶级用户把新用户信息记录到“所有用户信息”数组中；

步骤1.4.4：若已经到达最大值，便向顶级用户发送请求服务数据包，顶级用户便把自己直接下级用户的信息发送给新用户；新用户把收到的用户信息加入到自己的“备选上级用户”链表中，并向这些用户发送RTT测试包；新用户收到所有回送的RTT测试包后，选择一个RTT值较小且直接连接的单播用户数目未达到最大值的用户作为其上级用户；新用户再发送发现服务成功数据包给其选定的上级用户和顶级用户；顶级用户便把新用户信息记录到“所有用户信息”数组中；

步骤2：按照数据路由步骤，进行多媒体数据的发送接收；

步骤2.1：发送数据的用户先把多媒体数据按消息形式发送到顶级用户；

步骤2.2：顶级用户收到步骤2.1中发送的数据包后，按照顺序给该数据包一个以流的标号表示的全局有序的序列号，再按已建立的树型结构，根据自己下级用户的网络是否支持多播的原则分别以单播或者多播的方式向每一个下级用户发送该数据包；

步骤2.3：各用户收到数据包后，按照数据包的序列号排序，根据数据包所含数据内容的不同做不同的处理；

步骤2.4：当用户发现传输过程中出现差错时，树型结构中的用户将会按照下述差错修复步骤进行有效的差错修复：

步骤2.4.1：当用户发现接收到的数据包未按该数据包所规定的最晚期限达到时，便向它的上游用户发送NAK，即不确认请求；该NAK请求含有：丢失的数据包所有会话的标识、丢失的数据包所属的流标识和校验和、丢失的数据包所属消息的序号以及丢失的数据包在所属消息中的序号；

步骤2.4.2：上游用户接收到下游用户的NAK包后，首先判断是否还在该数据包的最晚传输期限内，若尚在该期限内，再判断是否有必要，若有必要，便启动一个定时器，其定时时间为上游用户到各下游所有用户的RTT的最大值，而且在定时器超时前不再接收相同的NAK请求；同时，向下游用户重传数据；

步骤2.5：当用户依照下述步骤判断出在数据传输过程中网络某段链路出现拥塞时，则进行流量和拥塞控制：

步骤2.5.1：当发送数据的用户判断从接收数据的用户发来的NAK请求包中所包含的丢失数据包的个数超过了设定的门限值，则表明网络出现了拥塞；

步骤2.5.2：发送数据的用户以指数级的形式降低发送速率，直至最小值，即，每次发送一个字节；

步骤2.5.3：发送数据的用户同时也在按下述步骤实时的探测网络拥塞情况，发现出现拥塞时，发送数据的用户同样以指数级的形式降低发送速率，直至最小值，即，每次发送一个字节：

发送数据的用户在发送数据时会给每个数据包都加上时间戳T_send，同时，发送数据的用户和每个中间用户在发送重传数据包时也包含时间戳T_send；

每个接受数据的用户对来自其直接上游用户的数据包或重传数据包计算T_send+接受用户处理该数据的时间，称为T_res，并把T_res报告给上游用户；

每个上游用户在收到T_res后，就可以计算出该用户的RTT值，并把下游用户RTT的最大值包含在下一个数据包或重传数据包中发送给下游用户；

发送数据的用户通过计算最近的测量值RTT_new和历史上往返时间的最低记录RTT_min之比(RTT_new/RTT_min)，就可按指数级的形式对发送速率进行调整；

步骤2.6：在交互式多媒体应用进行的过程中，当树型结构中的用户突然出现故障或某段链路出现故障时，其他用户将自动按照下述自修复步骤在短时间内进行树型结构的动态调整：

步骤2.6.1：树型结构中的每个用户会定期向它的上级用户发出存活包；上级用户会相应给下级用户一个响应；

步骤2.6.2：当一个用户向上级用户发送的存活包在一定时间间隔内没有收到响应，这个用户等待一段时间后，向多播地址和多播端口发出请求服务数据包，按照上述自组织步骤重新连接到树型结构中来；

步骤3：当一个用户退出时，它的下级用户会发现在一定时间间隔内收不到对自己发出的存活包的响应，则视为这个用户的退出，下级用户便按照上述自修复步骤重新构建树型结构。

本发明具有以下优点：

一、将参与到交互式多媒体应用的用户自动组织成一个树型结构。按照自组织步骤，可以实现在一个新用户加入应用时，自动将其连接到一个树型结构中来，该新用户无须知道它所要连接到的上一级用户的地址，只要知道顶级用户的地址，就可建立起很好的数据通路，达到很高效、可靠的数据传输；

二、本发明采用了层次数据结构模型数据命名方式如附图1所示。

一个会话中可能运行着多个相互独立的应用，比如音频、视频、白板等，它们的数据使用不同的频道传输，每个频道有一个在会话中唯一的频道标识。用户可以选择收听哪些频道，由于每个频道使用不同的多播地址，所以用户只能接收到他所收听的频道里的数据，而不会收到它没有收听的频道里的数据。这样做的好处是用户可以有选择地接收数据。比如他所在的网络带宽很小，无法传输视频数据，但可以传输音频数据，就可以选择收听音频频道而不收听视频频道，虽然看不到视频，但仍然可以参加会议。如果所有的数据都在同一个频道里发送(用同一个多播地址)，他就只能选择要么全接收，要么全不接收，结果由于网络带宽有限，根本无法参加会话。

可以有多个节点同时向一个频道发送数据，这些节点称为该频道的数据源或发送者。频道中从一个节点发出的一系列数据称为数据流，简称流。每个流都有一个在频道中唯一的流标识，是一个随机产生的32位整数。一个节点在一个频道中可以既是发送者，又是接收者，但如果收到了自己发出的数据就立即丢弃。

消息是数据流中一个对上层应用有意义的数据单元，比如一个白板操作，一个图象文件，一个视频帧等。每个消息都有一个在流中唯一的消息序列号。序列号是一个单调增的整数，由发送者确定。

数据段简称段，或称包，是数据在网络上传输的单元。每种网络都有其允许的最大段长，当消息长度超过最大段长时，需要把消息分成多个段才能在网络上传输，本发明提出的数据传输方法支持消息的分段和重组。每个数据段用它在消息中的位置(序号)作为标识。接收者每收到一个段时，就可以通过四元组(频道标识，流标识，消息序号，段位置序号)确定其在名字空间中的位置。

三、数据的路由简单高效。树型结构中的用户按照集中式路由步骤进行数据传输。该路由步骤使数据传输变得简单高效易于控制，是实现数据全局有序的前提。

四、本发明保证了数据的全局有序性。数据的全局有序对于交互式多媒体应用是很重要的，它保证参与到应用中的各个用户看到最终显示效果是一致的。

五、对于在传输过程中出现差错的数据可以进行有效的差错修复。按照差错修复步骤可以对所传输的多媒体数据进行有选择的差错修复。因为在多媒体应用中，不同的多媒体应用对数据的完整性有着不同的要求。有些应用对传输时延比较敏感，可以容忍一定程度的差错，如音频/视频数据。而有些应用则对数据的完整性要求很高，如实时远程教育中的白板应用。所以考虑到这些因素，差错修复步骤就提供了可选择的差错修复。

六、在网络出现拥塞时可以进行很好的流量控制。按照流量和拥塞控制步骤，在网络状况不好的时候发送端用户可以进行适宜的流量控制。由于目前因特网上大部分流量都是TCP，因此采用流量和拥塞控制步骤就可以做到TCP友好，不会不公平的夺走TCP流的带宽。只有这样才能使本传输方法在网络上安全的实施。

七、可以实现树型结构的自动修复。当树型结构出现故障，如用户退出或者故障以及链路断路时，自修复步骤可以自动修复树型结构，保证应用中的其他用户的多媒体数据传输不受任何影响，为用户带来了很大的方便。

我们将本文提出的传输方法和Lawrence Berkeley Laboratory提出的可靠数据传输方法SRM(Scalable Reliable Multicast)做了一个综合的测试比较，结论是本发明比SRM更适于交互式多媒体数据传输应用系统。

采用的是网络仿真软件NS2对这两种方法进行模拟仿真。在仿真中，我们采用两个簇的网络拓扑进行多媒体数据的传输，如附图1所示。图中所有的链路速率都是1.5Mbps，延迟是10ms，丢失率参数基本相同。测试表明，在传输数据的过程中，SRM在各种丢失率情况下修复延迟均呈现明显的单峰，其值都在0.5-1.0秒之间，我们以0.1％的情况进行说明。图中数据修复延迟3.9代表了所有延迟大于3.9的情况。如附图2显示，部分修复包出现了相当大的延迟。这说明了SRM在传输数据时修复延迟性能上的不稳定性，即对延迟的大小没有数量上的保证，很多甚至达到了秒级。

附图3中采用本发明的方法传输数据时表现了类似的分布图，但修复延迟显然比SRM的要小，一般在400ms以内。

所以，从NS2的模拟结果可以看出，本发明提出的方法在性能上比SRM效率高。

附图说明

图1为仿真中我们采用的两个簇的网络拓扑结构。

图2为SRM传输数据时的数据修复延迟分布图。

图3为本发明提出的方法传输数据时的数据修复延迟分布图。

图4为本发明采用的层次数据结构模型数据命名方式。

图5为本发明提出的实现多媒体数据传输步骤的总流程图。

图6为本发明提出的自组织步骤的流程图。

图7为本发明提出的集中式路由步骤的流程图。

图8为本发明提出的全局有序步骤的流程图。

图9为本发明提出的差错修复步骤的流程图。

图10为本发明提出的流量拥塞控制步骤的流程图。

图11为本发明提出的自修复步骤的流程图。

图12为本发明具体实施方式中新用户加入时的初始树型结构图。

图13为本发明具体实施方式中应用户加入后的树型结构图。

具体实施方式

下面结合附图及实施例更详细的说明发明的内容。

本实施例描述了一个新用户完成交互式多媒体数据传输的具体实现方法，该方法的实施例运行在配置如下的PC机上：

CPU：Intel Pentium(R)4；

主频：2.8GHz；

内存：256M；

操作系统：Microsoft Windows XP Professional版本2002 Service Pack 2；一些初始条件的设定：

设新用户加入时的初始树型结构见附图12。

多播地址为：225.6.7.8；多播端口为：3000；

新用户的IP地址为218.14.21.252；并且加入前知道顶级用户的IP地址和监听端口；

一个用户直接单播连接的下级用户数目的最大值为2；

当丢失数据包的个数为6时，需要进行流量和拥塞控制；

顶级用户的“所有用户信息”数组(memberArray)如下：

1	用户的IP地址ipMyAddr	166.111.250.19
			该用户直接上级用户的IP地址ipParentAddr	null
	是否是公网IP标识bIsPublic	True
			2	用户的IP地址ipMyAddr	219.224.140.180
该用户直接上级用户的IP地址ipParentAddr	166.111.250.19
		是否是公网IP标识bIsPublic		True
3	用户的IP地址ipMyAddr				210.77.176.66
		该用户直接上级用户的IP地址ipParentAddr	166.111.250.19
	是否是公网IP标识bIsPublic			True

主要步骤详细说明如下：

1新用户按照下述自组织的步骤连接到上述树型结构中来参与多媒体应用。具体步骤如下：

1.1该用户首先询问顶级用户本应用的多播地址和多播端口。

新用户向顶级用户发送对这个交互式多媒体应用会话的信息进行请求的数据包。结构如下：

数据包类型MsgType

MT_SESSIONINFO_REQ

顶级用户收到会话信息请求数据包后，将该会话的多播地址和多播端口送回给发送请求的新用户。响应会话信息请求的数据包结构如下：

数据包类型MsgType	MT_SESSIONINFO_RESP
		多播地址ipSessionAddr	225.6.7.8
多播端口nSessionPort	3000

1.2新用户向多播地址和端口发送服务请求数据包，来得知该多播域内是否已经存在有加入此多媒体应用的用户；

数据包类型MsgType

MT_SERVICE_REQ

1.3如果收到应答，即表明本多播域内已经有加入此应用的用户，则新用户选择给予它应答的用户作为其上级用户，并发送发现服务成功数据包给这个上级用户和顶级用户，顶级用户把新用户信息记录到“所有用户信息”数组中；

1.4如果新用户在一段时间(2s)内没有收到对步骤1.2中发送的服务请求数据包的响应，便依次执行以下步骤：

1.4.1新用户把顶级用户加入到自己的“备选上级用户”链表(candidateList)中。candidateList当前状态如下：

备选上级用户地址ipCandidateAddr	166.111.250.19
		备选上级用户到顶级用户的RTT值nRTT2Top	0
备选上级用户的直接下级用户是否被测试过bChildrenTested	false

并向顶级用户发送RTT测试包。RTT数据包结构如下：

数据包类型MsgType	MT_RTT
		发送RTT包的时间nSendTime	1102925782
接收RTT包的用户到顶级用户的RTT值nRTT2Top	0
		与接收端用户直接单播连接的用户数目是否已达最大值bIsUniMax	false

顶级用户收到RTT测试包后，将RTT测试包的3)、4)字段进行填充。然后将这个RTT测试包返回给新用户。RTT数据包结构如下：

数据包类型MsgType	MT_RTT
		发送RTT包的时间nSendTime	1102925782
接收RTT包的用户到顶级用户的RTT值nRTT2Top	0
		与接收端用户直接单播连接的用户数目是否已达最大值bIsUniMax	true

1.4.2新用户便对顶级用户发来的RTT测试包进行下述判断：与顶级用户直接连接的单播用户数目是否已经达到最大值；

1.4.3若未达到最大值(bIsUniMax为false)，便把顶级用户作为其上级用户，并发送发现服务成功数据包给顶级用户，顶级用户把新用户信息记录到“所有用户信息”数组中；

1.4.4若已经到达最大值(bIsUniMax为true)，便向顶级用户发送请求服务数据包。数据包结构如下：

数据包类型MsgType	MT_SERVICE_REQ
		已测试过的备选用户的IP地址ipCandidateAddr	166.111.250.19

将新用户的“备选上级用户”链表中，“备选用户IP地址”为顶级用户IP地址的元素的“新节点通过该备选上级用户连接到定级用户的RTT值”域填上相应的值，“该备选上级用户的直接下级用户是否被测试过的标识”设为TRUE。candidateList当前状态如下：

备选上级用户地址ipCandidateAddr	166.111.250.19
		备选上级用户到顶级用户的RTT值nRTT2Top	15
备选上级用户的直接下级用户是否被测试过bChildrenTested	true

顶级用户接收到请求服务数据包时，在“所有用户信息”数组中进行查询，将用户直接上级用户的IP地址等于数据包中第二参数(166.111.250.19)的用户的IP地址，放在请求服务应答数据包中，传送给新用户。“所有用户信息”数组的当前状态如初始条件描述。请求服务应答数据包结构如下：

数据包类型MsgType	MT_SERVICE_RESP
		可能提供服务用户的IP地址信息ipCandidateAddr	219.224.140.180
	210.77.176.66

新用户收到请求服务应答数据包后。将可能提供服务用户的IP地址加入到新用户的“备选上级用户”链表(candidateList)中。candidateList当前状态如下：

备选上级用户地址ipCandidateAddr	166.111.250.19
		备选上级用户到顶级用户的RTT值nRTT2Top	15
备选上级用户的直接下级用户是否被测试过bChildrenTested	true

                                                                                             

备选上级用户地址ipCandidateAddr	219.224.140.180
		备选上级用户到顶级用户的RTT值nRTT2Top	0
备选上级用户的直接下级用户是否被测试过bChildrenTested	false

                                                                                              

备选上级用户地址ipCandidateAddr	210.77.176.66
		备选上级用户到顶级用户的RTT值nRTT2Top	0
备选上级用户的直接下级用户是否被测试过bChildrenTested	false

并向该可能提供服务用户分别发送RTT测试包。RTT包结构如下：

数据包类型MsgType	MT_RTT
		发送RTT包的时间nSendTime	1102925894
接收RTT包的用户到顶级用户的RTT值nRTT2Top	0
		与接收端用户直接单播连接的用户数目是否已达最大值bIsUniMax	false

新用户收到可能提供服务用户回送来的RTT包后，选择一个直接单播连接的用户数目未达到最大值，且RTT值较小的用户(用户A)为它提供服务。接收到回送的RTT包结构如下：

从用户A回送来的RTT包：

数据包类型MsgType	MT_RTT
		发送RTT包的时间nSendTime	1102925894
接收RTT包的用户到顶级用户的RTT值nRTT2Top	12
		与接收端用户直接单播连接的用户数目是否已达最大值bIsUniMax	false

从用户B回送来的RTT包：

数据包类型MsgType	MT_RTT
		发送RTT包的时间nSendTime	1102925894
接收RTT包的用户到顶级用户的RTT值nRTT2Top	16
		与接收端用户直接单播连接的用户数目是否已达最大值bIsUniMax	false

新用户找到可以为它提供服务的用户后。清空“备选上级用户”链表(candidateList)，并将自身维护的“本用户信息”数据结构(nodeInfo)填好。nodeInfo结构如下：

到上级用户的RTT值RTT2Parent	30
		上级用户的IP地址	219.224.140.180

发送发现服务成功数据包给顶级用户和上级用户。发现服务成功数据包结构如下：

数据包类型MsgType	MT_SERVICE_FOUND
		提供服务用户的IP地址ipParentAddr	219.224.140.180
新用户IP地址	218.14.21.252
		与提供服务的用户是否在同一域内bInSameDomain	false

顶级用户收到发现服务成功数据包后，可判断出新用户是公网IP，在“所有用户信息”数组(memberArray)中加入该新用户信息，memberArray当前状态如下：

1	用户的IP地址ipMyAddr	166.111.250.19
			该用户直接上级用户的IP地址ipParentAddr	null
	是否是公网IP标识bIsPublic	true
			2	用户的IP地址ipMyAddr	219.224.140.180
该用户直接上级用户的IP地址ipParentAddr	166.111.250.19
		是否是公网IP标识bIsPublic		true
3	用户的IP地址ipMyAddr				210.77.176.66
		该用户直接上级用户的IP地址ipParentAddr	166.111.250.19
	是否是公网IP标识bIsPublic			true
		4	用户的IP地址ipMyAddr		218.14.21.252
该用户直接上级用户的IP地址ipParentAddr	219.224.140.180
			是否是公网IP标识bIsPublic	true

提供服务的上级用户收到发现服务成功数据包后，由于新用户与其不在同一多播域内(即bInSameDomain为false)，在“直接连接的单播孩子”链表(UnicastChildrenList)中加入该新用户的信息。UnicastChildrenList结构如下：

直接单播相连接用户的IP地址ipUniChildAddr

218.14.21.252

新用户加入进来后的树型结构见附图13。

2按照数据路由步骤，进行多媒体数据的发送接收(发送文本数据“12345”)；

2.1发送数据的用户先把含有该文本的数据包按消息形式发送到顶级用户；消息msg中，含有如下信息：

消息中所含数据的内容标识	MT_CHAT_SEND
		消息中所含数据的内容	12345

将数据发送到顶级用户的函数：

Sendmsg(msg，TOPSERVER_SOCKET，nStreamNo)；

其中，msg为含有数据的消息；TOPSERVER_SOCKET表示该数据消息发送到顶级用户；nStreamNo为该数据消息所属流的标号。

2.2顶级用户接收到该消息数据包msg后，按顺序给该数据包一个全局的序列号，本顶级用户自己对该消息进行相应的处理，并按照树型结构，根据自己下级用户的网络是否支持多播的原则分别以单播或者多播的方式将数据包传输给应用中的每个用户。顶级用户自己处理的响应函数为：

OnMsg(nType，msg，nSid)；

其中，nType为该消息所含数据内容的标识；msg为含有数据的消息；nSid为该消息所属流的标号。

发送给应用中每个用户的函数为：

SendMsg(msg)；

其中，msg为含有数据的消息。

2.3用户接收到数据包后，按照数据包的序列号进行处理。处理函数为：

OnMsg(nType，msg，nSid)；

其中，nType为该消息所含数据内容的标识；msg为含有数据的消息；nSid为该消息所属流的标号。

在这个函数里面用户就可以对于不同nType类型的msg消息做不同的处理。

2.4当新用户发现从A用户发来的序号为10(SEQ＝10)的消息中，第3号(SegNo＝3)数据包(段)丢失后，它将按照下述差错修复步骤进行有效的差错修复：

2.4.1新用户启动一个定时器，等待一段时间nTimeOut(大小为用户A到其下游用户的RTT的最大值)。即：

int nTimeOut＝CalcTimeOut(stream.m_nMaxRTT)；

定时器的启动函数为：

StartTimer(ID_TIMER_NACK，nTimeOut，stream.m_nSid)；

其中，ID_TIMER_NACK为该定时器标识；nTimeOut为该定时器的时间大小；stream.m_nSid为该定时器所属数据流的标号。

定时器ID_TIMER_NACK发生超时，即在所等待nTimeOut的时间内丢失的数据包没有达到，则向其上游用户A发送对该数据包的NAK请求。NAK请求数据包格式为：

消息头部分

NAK包头部分

NAK包数据部分

其中，消息头(SEG_HEADER)部分含有如下信息：

消息类型nSegType	ST_NACK
		保留字节nFlags	0
消息总长度nSegLen	(本NAK请求数据包的长度)
		丢失的数据包所属会话的标识nSessionID	26401
校验和nCheckSum	(只是对消息头部分的校验)
		丢失的数据包所属流的标识nStreamID	20

NAK包头(NACK_HEADER)部分含有如下信息：

本用户接收窗口左边界消息序号nSeqLow	9
		本用户接收窗口左边界数据包序号nSegNoLow	2
在本NAK包头后所接的NAK包的个数nCount	1
		用来计算RTT值的时间戳nTimeStamp	11029260302
本用户的IP地址	218.14.21.252

NAK包数据(NACK)部分含有如下信息：

丢失的数据包所属消息的序号nSeq	10
		丢失的数据包在所属消息中的序号nSegNo	3

2.4.2当上游用户A接收到下游发来的NAK包，首先判断该nSeq＝10，nSeqNo＝3的数据包是否需要重传。如果需要则启动一个定时器(大小等于上游节点到下游节点RTT的最大值)，并将该数据包重传，而且在定时器超时前不响应相同的NAK包。重传的数据包格式为：

消息头部分

重传数据包头部分

重传数据包数据部分

其中，消息头(SEG_HEADER)部分含有如下信息：

消息类型nSegType	ST_RETRANSMIT
		保留字节nFlags	0
消息总长度nSegLen	(本重传数据包的长度)
		丢失的数据包所属会话的标识nSessionID	26401
校验和nCheckSum	(只是对消息头部分的校验)
		丢失的数据包所属流的标识nStreamID	20

重传数据包头(DATA_HEADER)部分含有如下信息：

重传数据包所属消息的序号nSeq

10

重传数据包在所属消息中的序号nSegNo	3
		重传数据包头后所接数据包的个数nSegCount	1
用来计算RTT值的时间戳nTimeStamp	11029260432

2.5当用户发现在数据传输过程中网络某段链路出现拥塞时，按照下述流量和拥塞控制步骤执行：

2.5.1发送数据的用户A经过判断，发现从新用户发来的NAK请求包中所包含丢失数据包的个数超过了一个门限值；这个门限值设置如下：

#define MAX_NEW REQ  6

(用户A接收到NAK请求包的时候，只需看NAK包头部分的nCount字段值是否超过了MAX_NEW_REQ)。

2.5.2用户A以指数级的形式降低发送速率，直至最小值，即，每次发送一个字节。即：m_nBytesPerBurst＝max(m_nBytesPerBurst/2，MIN_BYTES PER_BURST)；

其中，m_nBytesPerBurst为每次发送的字节数；MIN_BYTES_PER_BURST为发送速率可降到的最小值(每次发送1字节)。

2.6在交互式多媒体应用进行的过程中，当树型结构中的用户A突然出现故障时，其他用户将自动按照下述自修复步骤在短时间内进行树型结构的动态调整：

2.6.1树型结构中的每个用户会定期向它的上级用户发出存活包。存活包的格式如下：

数据包类型MsgType

MT_HEARTBEAT_REQ

上级用户会相应给下级用户一个响应。响应数据包的格式如下：

数据包类型MsgType

MT_HEARTBEAT_RESP

2.6.2用户C向上级用户A发送的存活包在一定时间间隔(5s)内没有收到响应，则用户C按照以下步骤进行树型结构的自修复：即等待一段时间后，向多播地址(225.6.7.8)和多播端口(3000)发出请求服务数据包，进而按照上述自组织步骤重新连接到树型结构中来；

3当用户A退出时，下级用户C会发现在一定时间间隔(5s)内收不到对A发出的存活包的响应，则视为A这个用户的退出，则用户C便按照上述自修复步骤重新构建树型结构。

Claims (1)

1、在因特网上实现交互式多媒体数据传输的方法其特征在于：

首先在进行交互式多媒体数据传输的各台主机上设定：

参与传输的各节点即用户在传输过程中的地位是平等的；

对数据段采用的是层次数据结构模型的数据命名方式，每一个数据段是由下述四个元素组成的四元组来确定该数据段的空间位置的；

频道标识：每个频道有一个在会话中唯一的频道标识；

流标识：每个数据流都有一个在频道中唯一的流标识，它是一个随机产生的32位整数；

消息序号：每个消息都有一个在数据流中唯一的消息序列号，所述消息是指数据流中一个对上层应用有意义的数据单元，所述序列号是一个单调递增的整数，由发送者确定；

段位置序号：每个数据段用它在消息中的位置序号作为标识；

用一个树型结构的各节点来表示参与到这个交互式多媒体应用的所有用户终端，顶级用户的IP地址和监听端口是给定的；且一个用户直接单播连接的下级用户数目的最大值也是给定的；

在树型结构中的顶级用户内建立“所有用户信息”数组，其数据项会有每个用户的IP地址、每个用户的直接上级用户的IP地址和是否是公网IP的标识；

在树型结构中的每个要加入多媒体应用的新用户内建立“备选上级用户”链表，其数据项含有：备选上级用户的IP地址、新用户通过该备选上级用户直接达到顶级用户的时间，即RTT值、以及该备选上级用户的直接下级用户是否被测试过的标识；同时，还要建立一个发送服务成功数据包用的“本用户信息”数据组，其数据项含有提供服务用户的IP地址、新用户的IP地址以及和提供服务的用户是否在同一多播域内的标识；另外，还有一个由新用户向顶级用户发送RTT测试包用的数据组，其数据项为：新用户发送RTT测试包的时间、接收RTT测试包的用户到顶级用户的RTT值以及和接收RTT测试包的用户直接单播连接的用户数目是否已达到最大值的标识；

接着，本发明将依次按下述步骤进行：

步骤1：一个新用户按照下述自组织的步骤连接到上述树型结构中来参与多媒体应用；

步骤1.1：新用户询问顶级用户自己参与的多媒体应用的多播地址和多播端口；

步骤1.2：新用户向多播地址和端口发送服务请求，来得知该多播域内是否已经存在有加入此多媒体应用的用户；

步骤1.3：如果收到应答，即表明本多播域内已经有加入此应用的用户，则新用户选择给予它应答的用户作为其上级用户，并发送发现服务成功数据包给这个上级用户和顶级用户，顶级用户把新用户信息记录到“所有用户信息”数组中；

步骤1.4：如果新用户在一段时间内没有收到对步骤1.2中发送的服务请求的响应，便依次执行以下步骤：

步骤1.4.1：新用户把顶级用户加入到自己的“备选上级用户”链表中，并向顶级用户发送RTT测试包，顶级用户便把自己连接的单播用户数目是否达到最大值的标识填充到RTT测试包中，然后将这个RTT测试包返回给新用户；

步骤1.4.2：新用户便对顶级用户发来的RTT测试包进行下述判断：与顶级用户直接连接的单播用户数目是否已经达到最大值；

步骤1.4.3：若未达到最大值，便把顶级用户作为其上级用户，并发送发现服务成功数据包给顶级用户，顶级用户把新用户信息记录到“所有用户信息”数组中；

步骤1.4.4：若已经到达最大值，便向顶级用户发送请求服务数据包，顶级用户便把自己直接下级用户的信息发送给新用户；新用户把收到的用户信息加入到自己的“备选上级用户”链表中，并向这些用户发送RTT测试包；新用户收到所有回送的RTT测试包后，选择一个RTT值较小且直接连接的单播用户数目未达到最大值的用户作为其上级用户；新用户再发送发现服务成功数据包给其选定的上级用户和顶级用户；顶级用户便把新用户信息记录到“所有用户信息”数组中；

步骤2：按照数据路由步骤，进行多媒体数据的发送接收；

步骤2.1：发送数据的用户先把多媒体数据按消息形式发送到顶级用户；

步骤2.2：顶级用户收到步骤2.1中发送的数据包后，按照顺序给该数据包一个以流的标号表示的全局有序的序列号，再按已建立的树型结构，根据自己下级用户的网络是否支持多播的原则分别以单播或者多播的方式向每一个下级用户发送该数据包；

步骤2.3：各用户收到数据包后，按照数据包的序列号排序，根据数据包所含数据内容的不同做不同的处理；

步骤2.4：当用户发现传输过程中出现差错时，树型结构中的用户将会按照下述差错修复步骤进行有效的差错修复：

步骤2.4.1：当用户发现接收到的数据包未按该数据包所规定的最晚期限达到时，便向它的上游用户发送NAK，即不确认请求；该NAK请求含有：丢失的数据包所有会话的标识、丢失的数据包所属的流标识和校验和、丢失的数据包所属消息的序号以及丢失的数据包在所属消息中的序号；

步骤2.4.2：上游用户接收到下游用户的NAK包后，首先判断是否还在该数据包的最晚传输期限内，若尚在该期限内，再判断是否有必要，若有必要，便启动一个定时器，其定时时间为上游用户到各下游所有用户的RTT的最大值，而且在定时器超时前不再接收相同的NAK请求；同时，向下游用户重传数据；

步骤2.5：当用户依照下述步骤判断出在数据传输过程中网络某段链路出现拥塞时，则进行流量和拥塞控制：

步骤2.5.1：当发送数据的用户判断从接收数据的用户发来的NAK请求包中所包含的丢失数据包的个数超过了设定的门限值，则表明网络出现了拥塞；

步骤2.5.2：发送数据的用户以指数级的形式降低发送速率，直至最小值，即，每次发送一个字节；

步骤2.5.3：发送数据的用户按同时也在按下述步骤实时的探测网络拥塞情况，发现出现拥塞时，发送数据的用户同样以指数级的形式降低发送速率，直至最小值，即，每次发送一个字节：

发送数据的用户在发送数据时会给每个数据包都加上时间戳T_send，同时，发送数据的用户和每个中间用户在发送重传数据包时也包含时间戳T_send；

每个接受数据的用户对来自其直接上游用户的数据包或重传数据包计算T_send+接受用户处理该数据的时间，称为T_res，并把T_res报告给上游用户；

每个上游用户在收到T_res后，就可以计算出该用户的RTT值，并把下游用户RTF的最大值包含在下一个数据包或重传数据包中发送给下游用户；

发送数据的用户通过计算最近的测量值RTT_new和历史上往返时间的最低记录RTT_min之比(RTT_new/RTT_min)，就可按指数级的形式对发送速率进行调整；

步骤2.6：在交互式多媒体应用进行的过程中，当树型结构中的用户突然出现故障或某段链路出现故障时，其他用户将自动按照下述自修复步骤在短时间内进行树型结构的动态调整：

步骤2.6.1：树型结构中的每个用户会定期向它的上级用户发出存活包；上级用户会相应给下级用户一个响应；

步骤2.6.2：当一个用户向上级用户发送的存活包在一定时间间隔内没有收到响应，这个用户等待一段时间后，向多播地址和多播端口发出请求服务数据包，按照上述自组织步骤重新连接到树型结构中来；

步骤3：当一个用户退出时，它的下级用户会发现在一定时间间隔内收不到对自己发出的存活包的响应，则视为这个用户的退出，下级用户便按照上述自修复步骤重新构建树型结构。

Images