二、多點傳播網絡的體系結構
多點傳播網絡體系結構包括：多點傳播的基本工作原理、實作多點傳播的條件、多點傳播的位址配置設定方案及與MAC位址映射、Internet組管理協定。
2.1多點傳播的工作原理
組 播是一種允許一個或多個發送者（多點傳播源）發送單一的資料包到多個接收者（一次的，同時的）的網絡技術。多點傳播源把資料包發送到特定多點傳播組，而隻有屬于該多點傳播 組的位址才能接收到資料包。多點傳播可以大大的節省網絡帶寬，因為無論有多少個目标位址，在整個網絡的任何一條鍊路上隻傳送單一的資料包。圖1 為基于三種通訊方式的網絡結構和資料傳遞過程。
A: 單點傳播方式實作多點傳播功能 B: 多點傳播方式
C: 廣播實作多點傳播功能
圖1 三種通訊方式資料傳遞過程比較
從圖1的工作方式可以看出：
單點傳播（Unicast）傳輸：在發送者和每一接收者之間需要單獨的資料信道。如果一台主機同時給很少量的接收 者傳輸資料，一般沒有什麼問題。但如果有大量主機希望獲得資料包的同一份拷貝時卻很難實作。這将導緻發送者負擔沉重、延遲長、網絡擁塞；為保證一定的服務 品質需增加硬體和帶寬。
多點傳播（Multicast）傳輸：它提高了資料傳送效率。減少了主幹網出現擁塞的可能性。多點傳播組中的主機可以是在同一個實體網絡，也可以來自不同的實體網絡（如果有多點傳播路由器的支援）。
廣 播（Broadcast）傳輸：是指在IP子網内廣播資料包，所有在子網内部的主機都将收到這些資料包。廣播意味着網絡向子網主機都投遞一份資料包，不論 這些主機是否樂于接收該資料包。然而廣播的使用範圍非常小，隻在本地子網内有效，因為路由器會封鎖廣播通信。廣播傳輸增加非接收者的開銷。
2.2 實作IP多點傳播的前提條件
實作IP多點傳播傳輸，則多點傳播源和接收者以及兩者之間的下層網絡都必須支援多點傳播。這包括以下幾方面：
●主機的TCP/IP實作支援發送和接收IP多點傳播；
●主機的網絡接口支援多點傳播；
●有一套用于加入、離開、查詢的組管理協定，即IGMP（v1,v2）；
●有一套IP位址配置設定政策，并能将第三層IP多點傳播位址映射到第二層MAC位址；
●支援IP多點傳播的應用軟體；
●所有介于多點傳播源和接收者之間的路由器、集線器、交換機、TCP/IP棧、防火牆均需支援多點傳播；
目 前，IP多點傳播技術得到硬體、軟體廠商的廣泛支援，比如，新生産的以太網卡幾乎都支援多點傳播；Cisco的路由器不僅支援DVMRP、PIM路由協定、IGMP組管理協定，而且支援Cisco專有Cisco組管理協定CGMP，再如微軟的Windows 95支援IP多點傳播和IGMPv1，而Windows 98還支援IGMPv2。對于不支援IP多點傳播傳輸的中間路由器采用IP隧道（Tunneling）技術作為過渡方案。這些說明IP多點傳播技術的應用環境已基 本具備。
2.3 多點傳播位址配置設定與MAC位址
在多點傳播通信中，我們需要兩種位址：一個IP多點傳播位址和一個Ethernet多點傳播位址。其 中，IP多點傳播位址辨別一個多點傳播組。由于所有IP資料包都封裝在Ethernet幀中，是以還需要一個多點傳播Ethernet位址。為使多點傳播正常工作，主機應 能同時接收單點傳播群組播資料，這意味着主機需要多個IP和Ethernet位址。
IP位址方案專門為多點傳播劃出一個位址範圍，在IPv4中為D類地 址，範圍是224.0.0.0到239.255.255.255，并将D類位址劃分為局部連結多點傳播位址、預留多點傳播位址、管理權限多點傳播位址；在IPv6中為 多點傳播位址提供了許多新的辨別功能，圖2為IPv4和IPv6的多點傳播位址格式，其中IPv6中特殊域的定義見表1。
圖2 IPv4和IPv6的多點傳播位址格式 表1 IPv6中特殊域的定義
局部連結位址：224.0.0.0～224.0.0.255，用于區域網路，路由器不轉發屬于此範圍的IP包；
預留多點傳播位址：224.0.1.0～238.255.255.255，用于全球範圍或網絡協定；
管理權限位址：239.0.0.0～239.255.255.255，組織内部使用，用于限制多點傳播範圍；
2.3.1 以太網與FDDI多點傳播MAC位址映射
IP多點傳播幀都使用以0X0100.5EXX.XXXX的24位字首開始的MAC層位址，但隻有其中的一半MAC位址可以被IP多點傳播使用，剩下的MAC位址空間 的23位作為第三層IP多點傳播位址進入第二層MAC位址的映射使用。由于第三層IP多點傳播的28位位址不能映射到隻有23位的可用MAC位址空間，造成有32:1的位址不明确，是以主機CPU必須對收到的每一個多點傳播資料包做出判斷。這增加了主機CPU的開銷。此外，還産生抑制第二層區域網路交換的多點傳播擴散問 題。
2.3.2 令牌環網多點傳播MAC位址映射
令牌環網MAC位址格式與标準以太網MAC位址格式位序相反。令牌環網的缺點是其功能地 址位使得它對多點傳播位址映射的不明确性高達228:1，這意味着令牌環網上的多點傳播資料流将導緻令牌環網點的CPU被環路上的每一個多點傳播資料包中斷，從這個角 度來說，令牌環網不适合于多點傳播。
2.4 多點傳播樹
在單點傳播模型中，資料包通過網絡沿着單一路徑從源主機向目标主機傳遞，但在多點傳播模型中，多點傳播源向某一組位址傳遞資料包，而這一位址卻代表一個主機組。為了向所有接收者傳遞資料，一般采用多點傳播分布樹描述IP多點傳播在網絡裡經過的路徑。
多點傳播分布樹有四種基本類型：泛洪法、有源樹、有核樹和Steiner樹。
2.4.1 洪泛法（Flooding）
這是最簡單的向前傳送多點傳播路由算法，并不構造所謂的分布樹。其基本原理如下：當多點傳播路由器收到發往某個多點傳播位址的資料包後，首先判斷是否是首次收到該資料包，如果是首次收到，那麼将其轉發到所有接口上，以確定其最終能到達所有接收者；如果不是首次收到，則抛棄該資料包。
洪 泛法的實作關鍵是“首次收到”的檢測。這需要維護一個最近通過的資料包清單，但無需維護路由表。它适合于對多點傳播需求比較高的場合，并且能做到即使傳輸出現 錯誤，隻要還存在一條到接收者的鍊路，則所有接收者都能接收到多點傳播資料包。然而，洪泛法不适合用于Internet，因為它不考慮鍊路狀态，并産生大量的 拷貝資料包。此外，對于高速網絡而言，“首次收到”清單将會很長，占用相當大的記憶體；盡管它能保證不對相同的資料包進行二次轉發，但不能保證對相同資料包 隻接收一次。
2.4.2 有源樹
有源樹也稱為基于信源的樹或最短路徑樹（Shortest Path Tree：SPT）。它是以多點傳播源為根構造的從根到所有接收者路徑都最短的分布樹。如果組中有多個多點傳播源，則必須為每個多點傳播源構造一棵多點傳播樹。由于不同組 播源發出的資料包被分散到各自分離的多點傳播樹上，是以采用SPT有利于網絡中資料流量的均衡。同時，因為從多點傳播源到每個接收者的路徑最短，是以端到端 （end-to-end）的時延性能較好，有利于流量大、時延性能要求較高的實時媒體應用。SPT的缺點是：要為每個多點傳播源構造各自的分布樹，當資料流量 不大時，構造SPT的開銷相對較大。
2.4.3 共享樹
共享樹也稱RP樹（RPT），是指為每個多點傳播組標明一個共用根（彙合點RP或 核心），以RP為根建立的多點傳播樹。同一多點傳播組的多點傳播源将所要多點傳播的資料單點傳播到RP，再由RP向其它成員轉發。目前，讨論最多同時也是最具代表性的兩種共享 樹是Steiner樹和有核樹（CBT）。
Steiner樹是總代價最小的分布樹，它使連接配接特定圖（graph）中的特定組成員所需的鍊路數最 少。若考慮資源總量被大量的組使用的情況，那麼使用資源較少最終就會減少産生擁塞的風險。Steiner樹相當不穩定，樹的形狀随組中成員關系的改變而改 變，且對大型網絡缺少通用的解決方案。是以Steiner樹隻是一種理論模型，而非實用工具。目前，出現了許多Steiner樹的次優啟發式生成算法。
有 核樹是由根到所有組成員的最短路徑合并而成的樹。A. Ballardie在1997年9月的《基于核的多點傳播路由體系結構》（Core Based Trees (CBT) Multicast Routing Architecture）(RFC2189和RFC2201)中介紹了有核樹。關于它的進一步讨論見下文。
共享樹在路由器所需存儲的狀态資訊的數量和路由樹的總代價兩個方面具有較好的性能。當組的規模較大，而每個成員的資料發送率較低時，使用共享樹比較适合。但當通信量大時，使用共享樹将導緻流量集中及根（RP）附近的瓶頸。
2.5 組管理協定IGMP
主機使用IGMP通知子網多點傳播路由器，希望加入多點傳播組；路由器使用IGMP查詢本地子網中是否有屬于某個多點傳播組的主機。
●加入多點傳播組
當 某個主機加入某一個多點傳播組時，它通過“成員資格報告”消息通知它所在的IP子網的多點傳播路由器，同時将自己的IP子產品做相應的準備，以便開始接收來自該多點傳播 組傳來的資料。如果這台主機是它所在的IP子網中第一台加入該多點傳播組的主機，通過路由資訊的交換，多點傳播路由器加入多點傳播分布樹。
●退出多點傳播組
在IGMP v1中，當主機離開某一個多點傳播組時，它将自行退出。多點傳播路由器定時(如120秒) 使用“成員資格查詢” 消息向IP子網中的所有主機的組位址（224.0.0.1）查詢，如果某一多點傳播組在IP子網中已經沒有任何成員，那麼多點傳播路由器在确認這一事件後，将不再 在子網中轉發該多點傳播組的資料。與此同時，通過路由資訊交換，從特定的多點傳播組分布樹中删除相應的多點傳播路由器。這種不通知任何人而悄悄離開的方法，使得多點傳播路 由器知道IP子網中已經沒有任何成員的事件延時了一段時間，是以在IGMP v2.0中，當每一個主機離開某一個多點傳播組時，需要通知子網多點傳播路由器，多點傳播路由器立即向IP子網中的所有多點傳播組詢問，進而減少了系統處理停止多點傳播的延 時。
三、多點傳播轉發
由于多點傳播源是向多點傳播組發送資料包而非單點傳播模型中的具體目标主機，是以多點傳播路由器不能依靠IP包中的目标位址來決定如何轉發數 據包，而必須将多點傳播資料包轉發到多個外部接口上，以便同一多點傳播組的成員都能接收到資料包。這使多點傳播轉發比單點傳播轉發更加複雜。大多數現有多點傳播路由協定使用逆 向路徑轉發（RPF）機制作為多點傳播轉發的基礎。
3.1 逆向路徑轉發(Reverse Path Forward: RPF)
當多點傳播資料包到達路由器時，路由器作RPF檢查，以決定是否轉發或抛棄該資料包，若成功則轉發，否則抛棄。
RPF檢查過程如下：
●檢查資料包的源位址，以确定該資料包經過的接口，是否在從源到此的路徑上；
●若資料包是從可傳回源主機的接口上到達，則RPF檢查成功，轉發該資料包到輸出接口表上的所有接口，否則RPF檢查失敗，抛棄該資料包。
3.2 多點傳播轉發緩存
對于每一個輸入多點傳播資料包進行RPF檢查會導緻較大的路由器性能損失。是以，建立多點傳播轉發緩存時，通常由多點傳播路由确定RPF接口。然後将RPF接口變成多點傳播轉發緩存項的輸入接口。一旦RPF檢查程式使用的路由表發生變化，必須重新計算RPF接口；并更新多點傳播轉發緩存項。
3.3 TTL門檻值
每 當路由器轉發多點傳播資料包，IP包中的TTL（Time To Live）值都減1。若資料包的TTL減少到0，則路由器将抛棄該資料包。TTL門檻值可用于多點傳播路由器的各個接口，以防止在該接口上轉發低于TTL門檻值的 多點傳播資料包。這樣可對多點傳播的範圍加以控制。表2給出典型的初始TTL值和作為不同TTL邊界的路由器接口TTL門檻值。
表2 典型的TTL邊界值
| 範 圍 | 初始TTL值 | TTL門檻值 |
| 本地網 | 1 | N/A |
| 區域 | 15 | 16 |
| 地區 | 63 | 64 |
| 全球 | 127 | 128 |
3.4 管理權限邊界
除TTL門檻值外，多點傳播提供另一種稱為管理權限的位址機制作為邊界，以限制多點傳播資訊轉發到域外。管理權限的多點傳播位址是 從239.0.0.0到239.255.255.255，這段位址被認為是本地配置設定(類似于單點傳播中的192.168.xx.xx)，不能用于Internet。這種機制使得在Intranet内部可重複使用多點傳播位址，提高多點傳播位址空間的使用率。
四、多點傳播路由協定
要想在一個實際網絡中實作多點傳播資料包的轉發，必須在各個互連裝置上運作可互操作的 多點傳播路由協定。多點傳播路由協定可分為三類：密集模式協定（如DVMRP，PIM-DM）、稀疏模式協定（如PIM-SM，CBT）和鍊路狀态協定 （MOSPF），下面分别介紹各個協定的工作原理。
4.1 距離向量多點傳播路由協定（Distance Vector Multicast Routing Protocol：DVMRP）
DVMRP由單點傳播路由協定RIP擴充而來，兩者都使用距離向量算法得到網絡的拓撲資訊，不同之處在于RIP根據路由表前向轉發資料，而DVMRP則是基于RPF。為 了使新加入的多點傳播成員能及時收到多點傳播資料，DVMPR采用定時發送資料包給所有的LAN的方法，然而這種方法導緻大量路由控制資料包的擴散，這部分開銷限 制了網絡規模的擴大。另一方面，DVMRP使用跳數作為計量尺度，其上限為32跳，這對網絡規模也是一個限制。目前提出了分層DVMRP，即對多點傳播網絡劃 分區域，在區域内的多點傳播可以按照任何協定進行，而對于跨區域的多點傳播則由邊界路由器在DVMRP協定下進行，這樣可大大減少路由開銷。
4.2 開放式多點傳播最短路徑優先協定（Multicast Open Shortest Path First：MOSPF）
MOSPF是一種基于鍊路狀态的路由協定，是對單點傳播OSPF協定的擴充。
同OSPF類似，MOSPF定義了三種級别的路由：
●MOSPF區域内多點傳播路由：用于了解各網段中的多點傳播成員，構造（源網絡S，組G）對的SPT；
●MOSPF區域間多點傳播路由：用于彙總區域内成員關系，并在自治系統（AS）主幹網（區域0）上釋出組成員關系記錄通告，實作區域間多點傳播包的轉發。
●MOSPF AS 間多點傳播路由：用于跨AS的多點傳播包轉發。
區 域内MOFPF利用了鍊路狀态資料庫，對單點傳播OSPF資料格式進行擴充，定義了新的鍊路狀态通告（Link State Advertisement：LSA），使得MOSPF路由器了解哪些多點傳播組在哪些網絡上。路由器使用Dijkstra算法構造（源網絡S，組G）對的SPT。MOSPF與DVMRP相比，路由開銷較小，鍊路使用率高，然而Dijkstra算法計算量很大，為了減少路由器的計算量，MOSPF執行一種按 需計算方案，即隻有當路由器收到多點傳播源的第一個多點傳播資料包後，才對（S，G）SPT計算，否則利用轉發緩存（cache）中的（S，G）SPT。
MOSPF繼承了OSPF對網絡拓撲的變化響應速度快的優點，但拓撲變動使所有路由器的緩存失效重新計算SPT，因而消耗大量路由器CPU資源。這就決定了MOSPF不适合高動态性網絡（組成員關系變化大、鍊路不穩定），而适用于網絡連接配接狀态比較穩定的環境。另外，對于有大量多點傳播源子網絡的網絡而 言，MOSPF的擴充性問題引起了人們的關注，有待于進一步研究。
4.3 協定無關多點傳播（Protocol Independent Multicast：PIM）
PIM由IDMR（域間多點傳播路由）工作組設計，顧名思義，PIM不依賴于某一特定單點傳播路由協定，它可利用各種單點傳播路由協定建立的單點傳播路由表完成RPF檢查功能， 而不是維護一個分離的多點傳播路由表實作多點傳播轉發。由于PIM無需收發多點傳播路由更新，是以與其它多點傳播協定相比，PIM開銷降低了許多。PIM的設計出發點是在Internet範圍内同時支援SPT和共享樹，并使兩者之間靈活轉換，因而集中了它們的優點提高了多點傳播效率。PIM定義了兩種模式：密集模式(Dense-Mode)和稀疏模式（Sparse-Mode）
4.3.1 PIM-DM
PIM-DM與DVMRP很相似，都屬于密集模式協定，都采用了“擴散/剪枝”機制。同時，假定帶寬不受限制，每個路由器都想接收多點傳播資料包。主要不同之處在于DVMRP使用内建的多點傳播路由協定，而PIM-DM采用RPF動态建立SPT。
該模式适合于下述幾種情況：高速網絡；多點傳播源和接收者比較靠近，發送者少，接收者多；多點傳播資料流比較大且比較穩定。
4.3.2 PIM-SM
PIM-SM與基于“擴散/剪枝”模型的根本差别在于PIM-SM是基于顯式加入模型，即接收者向RP發送加入消息，而路由器隻在已加入某個多點傳播組輸出接口上轉發那個多點傳播組的資料包。
PIM-SM采用共享樹進行多點傳播資料包轉發。每一個組有一個彙合點（Rendezvous Point: RP），多點傳播源沿最短路徑向RP發送資料，再由RP 沿最短路徑将資料發送到各個接收端。這一點類似于CBT，但PIM-SM不使用核的概念。PIM-SM主要優勢之一是它不局限于通過共享樹接收多點傳播資訊， 還提供從共享樹向SPT轉換的機制。
盡管從共享樹向SPT轉換減少了網絡延遲以及在RP上可能出現的阻塞，但這種轉換耗費了相當的路由器資源，是以它适用于有多對多點傳播資料源和網絡組數目較少的環境。
4.4 有核樹多點傳播路由協定（Core-Based Trees: CBT）
CBT的基本目标是減少網絡中路由器多點傳播狀态，以提供多點傳播的可擴充性。為此，CBT被設計成稀疏模式（與PIM-SM相似）。CBT使用雙向共享樹，雙向共享樹 以某個核心路由器為根，允許多點傳播資訊在兩個方向流動。這一點與PIM-SM不同（PIM-SM中共享樹是單向的，在RP與多點傳播源之間使用SPT将多點傳播資料 轉發到RP），是以CBT不能使用RPF檢查，而使用IP標頭的目标組位址作檢查轉發緩存。這就要求對CBT共享樹的維護就需非常小心，以確定不會産生組 播路由循環。
從路由器建立的多點傳播狀态的數量來看， CBT比支援SPT的協定效率高，在具有大量多點傳播源群組的網絡中，CBT能把多點傳播狀态優化到組的數量級。
CBT為每個多點傳播組建立一個生成樹，所有多點傳播源使用同一棵多點傳播樹。CBT工作過程大體如下：
●首先選擇一個核，即網絡中多點傳播組的固定中心，來構造一棵CBT；
●主機向這個核發送join指令；
●所有中間路由器都接收到該指令，并把接收該指令的接口标記為屬于這個組的樹；
●如果接收到指令的路由器已是樹中一個成員，那麼隻要再标記一次該接口屬于該組；如果路由器第一次收到join指令，那麼它就向核的方向進一步轉發該指令，路由器就需要為每個組保留一份狀态資訊；
●當多點傳播資料到達一個在CBT樹上的多點傳播路由器時，路由器多點傳播資料到樹的核。以保證資料能夠發送到組的所有成員。
CBT将多點傳播擴張限制在接收者範圍内，即使第一個資料包也無需在全網擴散，但CBT導緻核周圍的流量集中，網絡性能下降。是以某些版本的CBT支援多個核心以平衡負載。
目前CBTv3草案已公布。該方案通過使用CBT邊界路由器（BR）更好地處理域間多點傳播的轉發。CBTv3還引入新的狀态及單向分支CBT概念。盡管CBT很有代表性，但至今卻幾乎沒有已實作的CBT網絡。
五、多點傳播應用與程式設計
多點傳播技術被認為是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;
struct in_addr imr_interface;
}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多點傳播技術必然有着廣闊的發展前景。
下面的代碼為Sender.cpp 檔案代碼
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <time.h>
#include <string.h>
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#define HELLO_PORT 12345
#define HELLO_GROUP "225.0.0.37"
int main(int argc, char *argv[])
{
struct sockaddr_in addr;
int fd, cnt;
struct ip_mreq mreq;
char *message="Hello, World!";
/* create what looks like an ordinary UDP socket */
if ((fd=socket(AF_INET,SOCK_DGRAM,0)) < 0)
{
perror("socket");
exit(1);
}
/* set up destination address */
memset(&addr,0,sizeof(addr));
addr.sin_family=AF_INET;
addr.sin_addr.s_addr=inet_addr(HELLO_GROUP);
addr.sin_port=htons(HELLO_PORT);
/* now just sendto() our destination! */
while (1)
{
if (sendto(fd,message, strlen(message), 0, (struct sockaddr *) &addr, sizeof(addr)) < 0)
{
perror("sendto");
exit(1);
}
sleep(1);
}
return 0;
}
下面的代碼為 Recver.cpp代碼
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <time.h>
#include <string.h>
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#define HELLO_PORT 12345
#define HELLO_GROUP "225.0.0.37"
#define MSGBUFSIZE 256
int main(int argc, char *argv[])
{
struct sockaddr_in addr;
int fd, nbytes,addrlen;
struct ip_mreq mreq;
char msgbuf[MSGBUFSIZE];
u_int yes=1; /*** MODIFICATION TO ORIGINAL */
/* create what looks like an ordinary UDP socket */
if ((fd=socket(AF_INET,SOCK_DGRAM,0)) < 0)
{
perror("socket");
exit(1);
}
/**** MODIFICATION TO ORIGINAL */
/* allow multiple sockets to use the same PORT number */
if (setsockopt(fd,SOL_SOCKET,SO_REUSEADDR,&yes,sizeof(yes)) < 0)
{
perror("Reusing ADDR failed");
exit(1);
}
/*** END OF MODIFICATION TO ORIGINAL */
/* set up destination address */
memset(&addr,0,sizeof(addr));
addr.sin_family=AF_INET;
addr.sin_addr.s_addr=htonl(INADDR_ANY); /* N.B.: differs from sender */
addr.sin_port=htons(HELLO_PORT);
/* bind to receive address */
if (bind(fd,(struct sockaddr *) &addr,sizeof(addr)) < 0)
{
perror("bind");
exit(1);
}
/* use setsockopt() to request that the kernel join a multicast group */
mreq.imr_multiaddr.s_addr=inet_addr(HELLO_GROUP);
mreq.imr_interface.s_addr=htonl(INADDR_ANY);
if (setsockopt(fd,IPPROTO_IP,IP_ADD_MEMBERSHIP,&mreq,sizeof(mreq)) < 0)
{
perror("setsockopt");
exit(1);
}
/* now just enter a read-print loop */
while (1)
{
//ssize_t recvfrom(int s, void *buf, size_t len, int flags, struct sockaddr *from, socklen_t *fromlen);
addrlen=sizeof(addr);
if ((nbytes=recvfrom(fd, msgbuf, MSGBUFSIZE, 0, (struct sockaddr *) &addr, (socklen_t *)&addrlen)) < 0)
{
perror("recvfrom");
exit(1);
}
puts(msgbuf);
}
return 0;
}
下面為 編譯 sender 和 recver 的Makefile 檔案
CC = gcc
CXX = g++
CFLAGS = -Wall -pipe -D_DEBUG -DDEBUG -g -O0
LDFLAGS = -lstdc++
RM = /bin/rm -f
MODULE_INC = -I../curl-7.21.3/include -I../boost_1_45_0 -I./
MODULE_LIB = -L../boost_1_45_0/stage/lib
CFLAGS += $(MODULE_INC)
LDFLAGS += $(MODULE_LIB)
LIBOBJS = Sender.o Recver.o
TARGET = sender recver
all: $(TARGET)
sender: Sender.o
$(CXX) -o $@ $^ $(LDFLAGS)
recver: Recver.o
$(CXX) -o $@ $^ $(LDFLAGS)
clean:
rm -f *.o
rm -f $(TARGET)
# make rule
%.o : %.c
$(CC) $(CFLAGS) -c $^ -o $@
%.o : %.cpp
$(CC) $(CFLAGS) -c $^ -o $@
install:
cp -f $(TARGET) ../bin/