技术领域本发明申请在于组播数据流分发组领域。更确切地，本发明申请涉及双向组播分发组以及订阅源自组播客户端的流。
背景技术：
在IP(互联网协议)网络中实现组播传输的服务最初被限制于分发源自组播服务器目的地为组播客户端的包。从而，在通过互联网进行电视分发的情况下，网络前端服务器或者由运营商控制、或者由运营商与之具有协议的内容提供商控制，由此允许运营商控制由客户端决定的服务质量。但是，通过允许每个组播客户端经由传输网络向组播组发送组播IP包，组播传输模式现在不再仅用于从服务器到组播客户端的下行方向上。如果一个客户端将大量比特率的组播IP流量发送至其他客户端所订阅的组播组的IP地址，则其他客户端的用于接入IP网络的接口冒着由于前者客户端的组播IP流量而达到饱和的风险。为了限制由组播客户端所接收的组播流的数量，组播客户端可以通过除了组播组的IP地址以外还指定有待例如借助于在规范IETFRFC3376(互联网工程任务组，征求评议文件)中定义的IGMPv3协议(互联网组管理协议)或在规范IETFRFC3810中定义的MLDv2协议(组播侦听发现)进行授权或排除的一个或多个源IP地址来要求网络接收组播流。在本文件的下文中，当组播客户端订阅由另一个客户端或服务器发送的组播流时，这意味着这另一个客户端或服务器的IP地址在组播流接收请求中被指定。专利申请WO2011/067495描述了一种用于控制IGMPv3或MLDv2请求的准入的方法，使得可以通过将所保证的下行比特率与经授权的上行比特率进行比较来限制有待向下发送回到客户端的组播流的数量，但是，这种方法假设这些比特率对于准入控制实体而言是已知的。这些比特率并不总是已知的。例如，当由通过Wi-Fi接入点接入网络的组播客户端来发送组播流时，情况就是如此。那么，不可能提前了解不同的上行IP组播流的比特率，因为不是所有的Wi-Fi终端都实施IEEE(电气与电子工程师协会)规范802.11e。本发明的目的之一是补救现有技术的这些缺点。
技术实现要素：
本发明借助于一种用于请求订阅在组播分发组中分发的数据流的方法来改进这种情形，所述组包括多个源，这些源包括服务器、第一客户端和第二客户端，所述源通过电子通信网络互连，该组播分发组由地址所标识，如果第二源之前是第一源的订户，则由该第一源发送至该组播组的地址的流被该第二源所接收，该第一客户端是该服务器的订户，该方法包括由该第一客户端实现的以下步骤：·接收源自该服务器的至少一条管理消息，该至少一条管理消息包括与该第二客户端发送至该组播组的地址的流相关的至少一个质量参数，·根据取决于所接收到的该至少一个质量参数的标准决定订阅该第二客户端，·在肯定决定的情况下，发送请求订阅该第二客户端的消息。借助于本发明，在订阅第二客户端之前，双向组播组的第一客户端从服务器获得由第二客户端发送的流的多个质量参数。从而，如果从服务器获得的一个或多个质量参数表明没有满足决定第一客户端订阅第二客户端的标准时，如例如，信号需求队列中的太多比特率或太多内存，则第一客户端可以决定不订阅该第二客户端。根据早期技术，在客户端订阅另一个客户端以便接收由该另一个客户端所发送的组播流之前，没有与这个流的质量相关的信息可供该客户端使用。根据本发明的一个方面，该决定步骤考虑包括为接收该第二客户端发送至该组播组的地址的流所必需的平均比特率的值在内的标准，并且前面是基于该至少一个质量参数计算这个值的步骤。包括在例如由组播服务器根据RFC3550发送的RTCPSR(实时传输控制协议，发送器报告)型管理消息中的质量参数为：所接收到的包的数量、所接收到的RTP包的有用字节的数量(实时传输协议)、以及自RTP会话开始以来丢失的RTP包的数量。因此，有利地，借助于这些质量参数，第一客户端可以计算由第二客户端所发送的流的平均比特率，该平均比特率与为了接收这个流所必需的平均比特率完全相同。根据本发明的一个方面，该决定步骤考虑包括为接收该第二客户端发送至该组播组的地址的流所必需的队列大小的值在内的标准，并且前面是基于该至少一个质量参数计算这个值的步骤。包括在例如由组播服务器根据RFC3611发送的RTCPXR(扩展报告)型管理消息中的质量参数为：丢失的RTP包的比率、由于晚到或早到而没有考虑在内的RTP包的比率、在突发期间丢失或没有考虑在内的RTP包的比率、在两次突发之间丢失或没有考虑在内的RTP包的比率。因此，有利地，借助于这些质量参数，第一客户端可以计算与由第二客户端所发送的流相关联的队列大小的值。根据本发明的一个方面，订阅请求消息包括所计算的值。所计算的比特率表示在第一客户端订阅第二客户端之前就比特率方面而言关于第一客户端已经接收到的事物的附加比特率。同样，所计算的队列大小表示在第一客户端订阅第二客户端之前就队列方面而言关于第一客户端已经接收到的事物的附加大小。有利地，借助于在其订阅请求中包括为接收该流而计算的平均比特率和/或计算的队列大小，如果第一客户端在不知道这个比特率或这个附加队列大小是否供其支配的情况下已经决定订阅，则其允许网络的接收该请求的另一个实体验证这个附加比特率在朝着第一客户端的下行方向上确实可用。刚刚已经描述的用于请求订阅数据流的方法的各方面可以彼此独立地或彼此组合地实现。在本发明的所有实施例中，本发明进一步涉及一种用于请求订阅数据流的装置，该装置能够实现刚刚已经描述的用于请求订阅数据流的方法。本发明还涉及一种用于管理在组播分发组中分发的数据流的方法，所述组包括多个源，这些源包括服务器、第一客户端和至少一个第二客户端，所述源通过电子通信网络连接在一起，所述组播分发组由地址所标识，如果第二源之前是第一源的订户，则由该第一源发送至该组播组的地址的流被该第二源所接收，该第一客户端是该服务器的订户，该服务器是所述至少一个第二客户端的订户，并且能够接收由该第二客户端发送至该组播组的地址的流，并且能够从其中提取与所述流的质量相关的至少一个参数，该方法包括由该服务器实现的以下步骤：·根据所提取的该至少一个参数从该至少一个第二客户端当中选择至少一个客户端，·向该组播组的地址发送至少一条管理消息，该少一条管理消息包括与该至少一个选择的客户端相对应的该至少一个提取的参数。因此，作为组播组的所有流的订户的服务器接收由该组播组的所有终端发送的所有流，具体包括由第一终端和第二终端发送至该组播组的地址的消息，例如，包括有效载荷数据以及其发送器的标识符的RTP型消息。因此，这允许服务器测量从这些终端接收到的有效载荷数据的某些质量参数并且使这些质量参数与这些终端相关联。因此，服务器变得能够以流的方式将包括一定数量的参数的管理消息发送至组播组的地址(也就是说该组的所有终端)，对于这些终端中的每个终端而言，这些参数将帮助决定订阅该组中的一个或多个其他终端的流。这些管理消息是例如RTCPSR或XR型消息，这些消息包括发送源的标识符以及某些质量参数，如字节的数量或在给定时间间隔内接收到的包的数量、丢失的包的数量、抖动等，这些参数代表在上行方向上该源(也就是说客户端)与网络中的节点之间的链路的质量。某些终端具有较差的上行流质量，这使得它们对于希望订阅组播组的流(服务器的那些除外)的其他终端而言是较差的候选者。借助于选择步骤，服务器可以从其管理消息中移除与上行流质量较差的终端相关的信息项，并且这将会将阻止这些其他终端认为它们是良好订阅候选者。有利地，根据本发明，相对于只要服务器一接收到RTP流就自动分派这类消息的早期技术，由服务器所发送的RTCPSR/XR消息的数量由此被减少。而且，与质量较差的流相关的管理消息仅可以由接收它们的那些终端困难地利用(如果真会发生的话)。借助于发送步骤，与早期技术相对比，终端只接收可利用的管理消息。在本发明的所有实施例中，本发明进一步涉及一种用于管理数据流的装置，该装置能够实现刚刚已经描述的用于管理订阅数据流的方法。本发明还涉及一种组播分发组的客户端设备项，该客户端设备项连接至电子通信网络并且包括如上所述的用于请求订阅数据流的装置。这个客户端设备项可以是例如用户终端，如智能电话、数字平板计算机、计算机或传感器。本发明还涉及一种组播分发组的服务器设备项，该服务器设备项连接至电子通信网络并且包括如上所述的用于管理数据流的装置。该服务器设备项可以是例如电视服务器、游戏服务器、视频会议服务器或者传感器网络服务器。本发明进一步涉及一种组播分发组，该组播分发组包括如上所述的服务器设备项和至少两个客户端设备项，这些设备项通过电子通信网络连接在一起。本发明还涉及一种计算机程序，该计算机程序包括多条指令，当由处理器执行刚刚已经描述的用于请求订阅数据流的方法时，这些指令用于实现这种方法的步骤。而且，本发明涉及一种由客户端设备项可读的记录介质，在该记录介质上记录刚刚已经描述的程序，该记录介质能够使用任何编程语言，并且能够采用源代码、目标代码、或源代码与目标代码之间的中间代码的形式，如采用局部编译的形式或者采用任何其他希望的形式。本发明还涉及一种计算机程序，该计算机程序包括多条指令，当由处理器执行刚刚已经描述的用于管理数据流的方法时，这些指令用于实现这种方法的步骤。最后，本发明涉及一种由服务器设备项可读的记录介质，在该记录介质上记录刚刚已经描述的程序，该记录介质能够使用任何编程语言，并且能够采用源代码、目标代码、或源代码与目标代码之间的中间代码的形式，如采用局部编译的形式或者采用任何其他希望的形式。附图说明在阅读了以下通过简单的说明性而非限制性示例给出的对本发明的具体实施例的说明以及对附图的说明后，本发明的其他优点和特性将变得更加清楚明显，在附图中：-图1以示意性方式呈现了根据本发明的一个方面的在网络中的包括若干源的组播分发组，这些源包括服务器，-图2呈现了将根据本发明的一个方面的用于请求订阅数据流的方法的步骤以及用于管理数据流的方法的步骤示例性地串接在一起以及这些步骤的示例性实现方式，-图3呈现了根据本发明的一个方面的用于请求订阅数据流的方法的步骤的通过客户端进行的示例性实现方式，-图4呈现了根据本发明的一个方面的用于管理订阅数据流的方法的步骤的通过服务器进行的示例性实现方式，-图5呈现了根据本发明的一个方面的用于请求订阅数据流的装置的示例性结构，-图6呈现了根据本发明的一个方面的用于管理数据流的装置的示例性结构。具体实施方式在后续说明中，基于IETF的组播分发协议介绍了本发明的若干实施例的示例，但是本发明还适用于其他协议，如例如，ATM(异步传输模式)或以太网、或者适合于传感器的传输协议，如ZigBee、蓝牙或Wi-Fi。图1以示意性方式呈现了根据本发明的一个方面的在网络中的包括若干源的组播分发组，这些源包括服务器。在这类具有地址aG的组播分发组G中，每个源连接至电子通信网络301(一般是IP型网络)，并且可以向包的aG发送包，到达网络301。这些源是或者客户端(如客户端201至20x)或者服务器(如服务器101)。至少，每个客户端201至20x订阅由服务器101所发送的具有地址aG的组播流。因此，所有客户端接收由服务器发送至aG的任何事物(如实线所指示)。只要客户端没有明确订阅由另一个客户端所发送的具有地址aG的组播流，该客户端就不接收由这另一个客户端发送的事物。在该客户端侧，服务器订阅由每个客户端201至20x所发送的具有地址aG的组播流。因此，服务器接收由客户端发送至aG的任何事物(如虚线所指示的)，由此，允许该服务器具体地接收这些客户端各自的RTP流量。在组播组中，客户端发送实时数据(又称为RTP流量)，并且控制消息(又被称为RTCP消息)。RTP包例如每十毫秒分发一次，但是RTCP控制消息以更低的频率(例如，每秒)进行分发。由服务器从客户端接收到的RTP流量允许该服务器获得与这个客户端所发送的流相关的信息项，并且发送RTCPSR或XR型消息，包括与服务器所接收到的这个客户端的流质量相关的参数。根据本发明，服务器选择其发送RTCPSR或XR消息所针对的那些客户端。相反，受到RFC3550约束，早期技术不在客户端与服务器之间进行区分，并且强迫服务器为组播组的所有客户端、或不为它们发送这类消息。有利地，根据本发明的服务器将不会选择例如质量参数展现出的值不足的客户端。根据本发明，希望订阅另一个客户端的客户端可以借助于从服务器接收到的RTCPSR或XR消息来计算为接收其流所必需的平均比特率，并且从而根据其可用的下行比特率来确定该客户端是否可以订阅。但是为了订阅，这个客户端必须知道其希望从中接收流并且其已经计算了所需平均比特率的客户端的IP地址。RTCPSR或XR消息(像RTP消息)不包括它们涉及到的流的任何源IP地址，而是仅包括SSRC(同步源)标识符，以便确保IP网络与组播网络之间的独立性。然而，服务器从客户端接收的SDES(源描述)RTCP消息允许其将IP地址与客户端的SSRC标识符相关联。实际上，除了该发送源的SSRC标识符，SDESRTCP型消息还包括另一个标识符，该另一个标识符包含这个源的呈ASCII形式的IPv4或IPv6地址。服务器可以向地址aG重新发送从不同客户端接收到的SEDSRTCP消息，或者将它们聚合以便向地址aG发送聚合的SDESRTCP消息。当客户端接收到聚合的SDESRTCP消息时，这允许该消息使其他客户端的IP地址与它们的SSRC标识符相关联。出于至少两个原因，这是有必要的：1.第一个原因在于：订阅客户端的请求(使用IGMPv3或MLDv2请求)必须指定这个客户端的IP地址，而根据RFC3550的RTCPSR或XR消息仅指定源的SSRC标识符；2.第二个原因在于：SSRC标识符在组播组中必须是唯一的，并且仅订阅由服务器所发送的组播流的客户端不知道已经使用的SSRC标识符并且可能被很好地分配以已经采用的标识符，由此引起对相冲突的客户端造成组播分发质量降低。图2呈现了将根据本发明的一个方面的用于请求订阅数据流的方法的步骤以及用于管理数据流的方法的步骤示例性地串接在一起以及这些步骤的示例性实现方式。为了易于说明，在图中将客户端的数量减少到两个，即，希望订阅除了服务器以外的第二源的第一客户端201、以及单个第二客户端202。以下解释还适用于若干个第二客户端202、203、204等与第一客户端201和服务器101形成组播组的一部分的情况。在步骤E400期间，服务器101通过将IGMPv3或MLDv2请求发送至网络301、将地址aG指定为组播组地址并且不排除任何源地址来订阅至组播地址aG的流集合。在步骤E500期间，服务器101开始使用其源地址S向组播地址aG发送RTP流量。只要客户端201或202不单独是地址S发送至组播地址aG的流的订户，它们都不接收这个流量或由地址S发送的任何其他流量。在步骤E401期间，客户端201通过将IGMPv3或MLDv2请求发送至网络301、将地址aG指定为组播组地址并且将地址S指定为源地址来订阅由地址S发送至组播地址aG的流。客户端201开始接收由地址S(也就是说由服务器)针对组播组发送的RTP流量。在步骤E601期间，客户端201发送SDESRTCP消息，该消息包括其自身的地址IP1以及其自身的标识符SSRC1。在步骤E501期间，客户端201使用其源地址IP1向组播地址aG发送RTP流量。在步骤E402期间，客户端202通过将IGMPv3或MLDv2请求发送至网络301、将地址aG指定为组播组地址并且将地址S指定为源地址来订阅由地址S发送至组播地址aG的流。客户端202开始接收由地址S(也就是说由服务器)针对组播组发送的RTP流量。在步骤E602期间，客户端202发送SDESRTCP消息，该消息包括器自身的地址IP2以及其自身的标识符SSRC2。在步骤E502期间，客户端202使用其源地址IP2向组播地址aG发送RTP流量。在步骤E503期间，之前已经接收到目的地为组播地址aG的RTP流量，服务器101根据在其各自的RTP流量中所获得的参数来从源201和202当中选择至少一个客户端。在步骤503期间，服务器101可以通过验证在RTP包的包头中所包含的序列号的连续性来确定接收自源的RTP流量是否展现出包丢失。在不存在包丢失的情况下，服务器101可以例如决定只选择源客户端。可以采用其他选择标准，如过度间隔到达抖动(inter-arrivaljitter)，间隔到达抖动在RFC3550中进行了定义。为了方便解释，下文中假设客户端202是在这个步骤E503期间在这些客户端中选择的。在步骤E600期间，服务器101生成并发送聚合的SDESRTCP消息，该消息由源自在步骤E503期间选择的客户端、在步骤E601和E602之后接收到的SDESRTCP消息的提取内容组成。接收聚合的SDESRTCP消息的客户端从而可以获知与其他客户端的SSRC相关联的IP地址并且检测可能的SSRC冲突。在步骤E603期间，客户端201接收聚合的SDESRTCP消息并且存储其所包含的{IP地址，SSRC标识符