组播应用与编程

组播技术被认为是WWW技术推广之后出现的最激动人心的网络技术之一。1992年出现支
持IP组播的Mbone(组播主干网)和Mbone桌面工具；1993-1996年IP Multicast成为业界关注
的焦点，然而因发展条件不成熟使得IP组播只为业界所关注；进入1999年以来，IP组播具备
了发展的三个关键条件：支持组播的路由协议；基于开放标准的可测试管理协议；因商业发
展机遇而进入高速发展阶段。又一次掀起了组播实践的高潮，下面将有关组播应用作简单讨
论： 
5.1 组播主干网(Multicast Backbone：Mbone) 
Mbone是一个由IETF开发的运行在Internet上的虚拟重叠网络。Mbone的初衷是创建一个半永
久的IP组播测试床而不需要等到整个Internet都采用支持组播的路由器。 
Mbone跨越几个洲，用户数大约在10000-30000之间。在IETF会议期间，大约有1000个不同的
接收主机接入。它成为Internet上传送声音和视频信息的一个重要组成部分。 
1992年，组播技术还处于实验阶段。当时提出以IP遂道（Tunneling）联结组播岛，组播岛
是支持组播服务的区域，最小的组播岛是一个支持组播的LAN。 
Mbone使用DVMRP协议，而DVMRP在UNIX下是由标准守护进程mrouted得以实现，所以许多用户
使用UNIX主机接入Mbone。由于UNIX主机上的I/O处理能力、对IP遂道的处理能力、网络接口
数量等方面都不及商用路由器，这都无形制约了Mbone的发展。 
Mbone自从出现就不断发展。今天，从基于mrouted的UNIX主机到商用路由器的迁移已超过了
50%；Mbone也采用剪枝、封装等技术。新的域间组播路由协议和转发算法、流量控制与管
理、可靠组播也将对Mbone产生影响。 
5.2 组播应用程序接口与编程 
RFC1112推荐了一些支持组播的应用程序接口： 
●加入一个组播组； 
●离开一个组播组； 
●为调整范围对一个组播数据的IP TTL值进行设定； 
●为组播传输和接收设定本地的接口； 
●禁止输出的组播数据回送。 
现在，许多TCP/IP实现都支持RFC1112所提到的要求，下面简要介绍UNIX(Berkeley Socket)
和Windows(Winsock) API。 
5.2.1 Berkeley Socket组播API 
所有Berkeley Socket API都采用setsockopt()的“套接字选项”功能来设置（对于某些选
项，getsockopt()功能可用来获得当前的设置）。表3描述了Berkeley BSD的set sockopt
()/getsockopt()组播命令。 
表3 BSD setsockopt()/getsockopt()组播命令的说明
 
setsockopt()/getsockopt()组播命令 
 命令说明 
 
IP_MULTICAST_TTL 
 设置输出组播数据的TTL值 
 
IP_ADD_MEMBERSHIP 
 在指定接口上加入组播组 
 
IP_DROP_MEMBERSHIP 
 退出组播组（在IGMPv2中实现） 
 
IP_MULTICAST_IF 
 获取默认接口或设置接口 
 
IP_MULTICAST_LOOP 
 禁止组播数据回送 
 
 
对于套接字编程，首先要使用函数socket()建立一个数据包套接字，然后用bind()函数将套
接字与一个地址和端口号连接起来。 
为了发送一个组播数据包，需要在sendto()调用中指定一个组播地址作为目的地址（所有IP
地址都使用网络字节顺序）。 
为了接收一个组播数据包，需要在recvfrom()调用中指定所要接收的组播地址。 
IP_MULTICAST_TTL允许将随后的组播数据的TTL设定成从0到255之间的任何值，例如： 
u_char ttl; 
setsockopt(sock,IPPROTO_IP,IP_MULTICAST_TTL,&ttl,sizeof(ttl)); 
关于TTL的讨论见上文。 
通过IP_MULTICAST_IF,系统管理员可在安装的时候为组播创建默认的接口（为从一个给定的
网络接口并发传送，一个网络接口会忽略这个默认值）。例如： 
struct in_addr addr; 
setsockopt(sock,IPPROTO_IP,IP_MULTICAST_IF,&addr,sizeof(addr)); 
在这里，addr是希望输出接口的本地IP地址，可使用一个INADDR_ANY地址来回送到默认的接
口。 
当组播组中的一台主机发送组播数据到输出接口时，默认的IP层将为本地回送数据的拷
贝。 
IP_MULTICAST_LOOP网络参数控制IP层是否回送所送的数据。例如： 
u_char loop; 
setsockopt(sock,IPPROTO_IP,IP_MULTICAST_LOOP,&loop,sizeof(loop)); 
将loop设置为0则禁止回送，设置为1则允许回送。 
为了能够接收IP组播数据，主机必须加入某个或多个组播组，程序通过使用IP_ADD_MEMBERSHIP网络接口参数向主机提出加入组播组的申请。例如： 
struct ip_mreq 
{struct in_addr imn_multiaddr; /* multicast group to join */ 
struct in_addr imr_interface; /* interface to join on */ 
}mreq; 
setsockopt(sock,IPPROTO_IP,IP_ADD_MEMBERSHIP,&mreq,sizeof(mreq)); 
一个组的成员是与一个单一的网络接口相联系；主机可在不止一个网络接口上加入相同的
组。若选择默认组播接口，要将imr_interface设置为INADDR_ANY;若选择主机其中一个本地
地址，要将imr_interface设置为特定的组播接口。 
若撤消一个成员资格，使用IP_DROP_MEMBERSHIP 
struct ip_mreq mreq; 
setsockopt(sock,IPPROTP_IP,IP_DROP_MEMBERSHIP,&mreq,sizeof(sreq)); 
其中mreq包含了在IP_ADD_MEMBERSHIP命令中相同的值。 
5.2.2 Windows Socket组播API 
基于Winsock1.1的组播编程与Berkeley Socket类似，这里不再赘述。Winsock2是
Winsock1.1的扩展，除兼容Berkeley Sockets组播API外，它还定义了一套支持IP组播的协
议独立API，如表4所示： 
表4 WinSock 2的协议独立组播API说明
 
WSAEnum Protocol() 
 获得协议信息结构(WASPROTOCOL_INFO) 
 
WSASocket() 
 设置组播类型 
 
WSAJoinLeaf 
 加入组播组并指定角色(发送者/接收者) 
 
WSAIoctl(…SIO_MULTICAST_SCOPE…) 
 设置IP TTL 
 
WSAIoctl(…SIO_MULTICAST_LOOPBACK…) 
 禁止组播数据回送 
 
 
在Winsock2中，定义了“数据平面”（Data Plane）和“控制平面”(Control Plane)的概
念，其中，数据平面决定在不同的网络成员之间数据如何传送；控制平面定义网络成员的组
织方式； 这两方面的特征既可以是“有根的”（Rooted）,也可以是“无根的”
（Nonrooted）。在“有根的”控制平面内，存在一个特殊的组播组成员，称作C_root（根
节点），其余的组成员称作C_leaf(叶节点)。对“无根的”控制平面而言，只存在叶节
点。 
在“有根的”平面中，根节点负责组播的建立，以及同任意数量叶节点的连接。叶节点可申
请加入一个特定的组播组。数据传送只能在根节点和叶节点之间进行，根节点将数据组播到
每个叶节点。 
在“无根的”平面中，只存在叶节点，它们可以任意加入一个组播组。从叶节点发送的数据
会组播到每一个叶节点。 
由于篇幅所限，有关Winsock API的进一步讨论，请参阅参考文献[3]、[5]和MSDN。 
　 
六、IP组播中存在的问题与发展 
6.1 组播的可靠性 
IP组播数据包典型使用用户数据报协议（UDP），而UDP是一种“尽力而为”（Best-
effort）协议。因此，IP组播应用必定会遇到数据包丢失和乱序问题。 
从端到端传输延迟和可靠性方面考虑，组播应用可大致分为三类： 
1）实时交互应用，如视频会议系统，这类应用对可靠性要求相对较低，但对端到端传输延
迟和网络抖动的要求很高。 
2）实时非交互型应用，如数据广播，这类应用传输延迟要求相对前一类应用较低，但在一
定延迟范围内，却对可靠性提出更高要求。 
3）非实时应用，如软件分发，这类应用中，可靠性是最基本的要求，在满足可靠性要求的
前提下，必须保证传输延迟在可接受的范围之内。 
对于不同类型的应用必须在确认方式（肯定确认ACK和否定确认NACK），集中确认与分布确
认、重传机制、重传范围、流量控制、拥塞控制、end-to-end延迟和广播延迟、网络抖动、
可伸缩性与网络的异构性等方面做出综合考虑，提出相应的解决办法。 
迄今为止，尽管在广域网环境中已经存在许多可靠组播协议，包括可靠组播协议RMP
（Reliable Multicast Protocol）、可扩展可靠组播SRM(Scalable Reliable 
Multicast)、基于日志的可靠组播LBRM（Log-Based Reliable Multicast）和可靠组播传输
协议RMTP(Reliable Multicast Transport Protocol)，但组播的可靠性研究仍然是国际上
的重点研究课题之一。 
6.2 组播的安全性 
安全组播就是只有注册的发送者才可以向组发送数据；只有注册的接收者才可以接收组播数
据。然而IP组播很难保证这一点。 
首先，IP组播使用UDP，任何主机都可以向某个组播地址发送UDP包，并且低层组播机构将传
送这些UDP包到所有组成员。其次，Internet缺少对于网络层的访问控制。第三，组成员可
以随时加入/退出组播组。这几点使组播安全性问题同组播的可靠性问题一样难以解决。 
总的来说，安全组播可分为集中式和分布（分层）式密钥管理体系。目前，对于组播安全性
问题已有Naïve密钥管理、Iolus、Nortel框架和SRM（Secure Reliable Multicast）等解
决方案。Matthew J. Mayer等人在[29]中提出了安全组播评估标准，回顾并讨论了安全组播
体系结构、组密钥管理和信源认证等问题。然而现有的解决方案都不同程度的存在不足，安
全组播仍然是一个技术难点。 
6.3 网络的异构性导致组播的复杂性 
Internet是一个异构网络，这种异构性表现在很多方面。第一，Internet的低层硬件平台千
差万别，可以是Ethernet、ATM、FDDI、令牌环网、帧中继、串行链路（PSTN、xDSL）、无
线网络、卫星网络、移动网络等等。这些低层网络具有不同的带宽、硬件存取控制方式、时
延特征。在多链路情况下，各链路的带宽与代价也可能不同。另外，某些网络平台的数据链
路具有非对称性，比如xDSL和卫星网络。第二，主机的硬件处理能力和操作系统各不相同。
就操作系统而言，主要的操作系统，如UNIX、Windows、MacOS、OS2有不同的变种和版本，
对IP组播的支持程度、进程的调度与管理、TCP/IP的实现方式和API都有差异。第三，互连
设备的差异。路由器、交换机、网络服务器在背板能力、包转发率、支持的路由协议的互操
作性。这些异构性都导致在实现IP组播网络中的复杂性。 
比如：网络中不同部分的带宽不同、接收者的处理要求和处理能力不同，而所有接收者都要
与同一组播源交互，这就要求采取某些方法使得每一个接收者接收到与其接收能力和从组播
源到接收者之间带宽相适合的数据流（即公平性）。再比如：ATM面向连接的特点在IP组播
传输中带来了新的问题，这使IP组播与ATM组播具有不同特点。 
所以，在设计IP组播网络时，必须充分考虑到网络的异构性。 
　 
七、结束语 
本文从组播的产生和发展出发，介绍了组播网络的体系结构、算法和协议，讨论了组播技术
的应用，总结了组播技术的难点。随着高宽带多媒体应用的迫切需求、ISP、ICP对IP组播网
络的支持、设备提供商的投入、各种专业组织的介入，IP组播技术必然有着广阔的发展前
景。