急!!有那位仁兄咱广域网中实现过多播

我也想知道,我在局域网中多播成功,在广域网却失败了,后来看了TCP/IP协议，好像在广域网中多播还不能实现。

在广域网中只能组播,不能广播.

                     -----------------------------
                          为了得到我应该得到的
                          为了找回我曾经失去的

多播和组播是同一回事,不同于广播.
那请问组播是如何实现的,fengge8ylf?

广域网中不能多播吧？如果能得话，岂不乱套了，大家的数据可以到处乱发！

不是那么回事,多播需要加入组之后才能够接收到数据,也正因为此,故又叫组播.别人未加入组的是没法收到数据的.只是有一个可能是:向某一个组只发送数据而不接收数据的话,可以不用加入组,只需向该组发送数据即可.
在广域网中肯定是能够实现多播的,只是现在都是一些大型的公司在做这方面的试验,而我们很少有比较全面的资料可参考,而且小型公司也没法做,或很难做.

我几个月前做过这方面的实验了~~同样也只是在局域网中成功~~
多播本身的定位应该是广域网中使用的 ~~~ 所以会有生存期的概念 ~~~
不过多播的频繁使用势必造成网络数据的泛滥 ~~ 而且我听说大概是98年以后产的网络硬件产品就已经可以支持多播了 ~~ 因此我猜测应该是网络硬件没有开启相应的服务吧 `~~ 
不对之处请各位指教

提几点：
一组播的地址有限，如果广域网，可能有冲突的组。
二。isp, router都有限制组播的要求。

提几点：
一、组播地址有限，广域网，可能会有组播地址冲突。
二、ISP,router都有限制组播（router有的可以启动组播）

那么,多播地址是否也需要申请呢.据了解,它的地址--我们可以使用的都属于动态分配的地址.固定的好像只用于协议等使用.

Internet上的多媒體群體廣播架構

(The Framework for Multicast Multimedia Presentation over Internet)

　

黃崇明 龔旭陽 劉沛川

國立成功大學 資訊工程研究所

　

摘要

在目前的網路應用服務中，多方多媒體播放系統 (Multiparty Multimedia Presentation System)，例如視訊會議 (Video Conference) 無疑地將是重要的一項，因為它可以帶來可觀的時間與經濟上的效益。但是如果想在網路上達到多方的即時多媒體資料播放，在網路通訊技術部份，必須藉由群體廣播 (Multicast) 的功能才有可能達成。在本篇論文中，我們介紹現今最普遍的網際網路 (Internet) 的群體廣播通訊協定 (protocols)，並利用現行的網際網路群體廣播通訊協定，提出一個傳輸層 (Transport layer) 之上的多方多媒體網路架構 (Multiparty Multimedia Network Architecture)以及多方多媒體播放系統 (Multiparty Multimedia Presentation System)，目的在達成於網路上進行多方的即時多媒體資料播放，並利用多方多媒體播放系統中的資料同步 (synchronization)機置，達成較為平順的多媒體播放服務品質 (QoS)。

1. Introduction

隨著網路知識的普及以及多媒體電腦的盛行﹐並且拜網路傳送技術的提昇，及壓縮儲存技術的突破﹐諸如隨選電影觀賞 (Movie On Demand)﹑視訊會議 (Video Conference)﹑或遠距教學 (Distant Learning)﹐都將漸漸走入我們的生活之中。隨著網際網路 (Internet) 的狂熱流行，及其逐漸深入各個社會層次的事實， 因此如何在現行的網際網路上，成功地實現這些應用，將會是一大挑戰。在這些應用中，不管是聲訊會議 (Audio Conference)，隨選電影觀賞 (Movie on Demand)， 或視訊會議 (Video Conference)，就網路傳輸技術部份而言，皆是採用群體廣播 (multicast) [1,3,4,10,11,13]。

所謂群體廣播乃是指資料只傳輸給屬於某同一群體 (Group) 的成員們 (membership)。而這些成員 (members)，則可能分別分佈在不同的網路上，並且具有相同的網路地址 （network address）。由此特性可知，群體廣播會比一次只對一個網路節點 (network node) 作傳輸的單一傳播 (unicast)，更節省網路頻寬 (bandwidth) 和網路地址 (network address) 的使用。網際網路的通訊協定 (protocol) 為網際網路協定 (Internet Protocol, IP)。架構在網際網路上的群體廣播通訊協定計有(1)定義群體廣播定址方式與功能的文件RFC1112 [2]，(2)定義群體成員的加入 (join) 與離開 (leave) 功能的網際網路群體管理協定 (Internet Group Management Protocol, IGMP) [15]，(3)定義在網際網路的群體廣播路由器(Multicast Router)中，找出供群體廣播資料傳輸路徑的距離向量群體廣播路由協定 (Distance Vector Multicast Routing Protocol, DVMRP) [16]，以及(4)定義找出所有路由路徑 (routing path) 中最短者 (shortest path) 的群體廣播開放最短路徑協定 (Multicast Open Shortest Path First protocol, MOSPF) [12]。

過去數年來，有關群體廣播的研究大都針對傳輸層 (Transport layer) 之下的通訊協定、架構、和系統，非常少的研究是專注於傳輸層之上的通訊協定、架構、和系統。由於多媒體的出現，定位於傳輸層以上，但在應用層 (Application layer) ，即應用軟體系統，之下的通訊協定、架構、和系統將日漸重要且需要。若以較淺顯的定義來看，即是位在視訊框架層次 (a video frame level) 的通訊協定、架構、和系統。因此在本論文中，我們將利用在網際網路上現有的群體廣播通訊協定，提出多方多媒體網路架構 (Multiparty Multimedia Network Architecture) 以及多方多媒體播放系統 (Multiparty Multimedia Presentation System)。

多方多媒體網路架構 (Multiparty Multimedia Network Architecture)，以OSI七層網路來看，是位在傳輸層之上，即會議層 (session layer)、表達層 (Presentation layer) 與應用層 (Application layer) 之中。多方多媒體網路架構，係在每一個想達到多方多媒體播放 (例如訊會議) 的區域網路上，皆設有一個多方多媒體伺服器 (Multiparty Multimedia Server) 來管理其區域網路上，所屬的終端多媒體播放電腦 (Multimedia Presentation Clients)。終端電腦可能為網路電腦 (Networking Computers，NC)、Basic Computers、Set-Top-Box、網路電視 (Networking TV) 等。每一個終端電腦，皆可以藉由多方多媒體伺服器的控制，而自由的加入某群體 (Group) 作多媒體的播放，並且可以藉由多方多媒體伺服器的多媒體資料同步 (synchronization) 功能，來補償 (compensate) 由於網路擁緊所造成的多媒體資料訊號間差與歪斜誤差 (jitters and skews) [5,6,8,9,14,17]，而達到較為平順 (smooth) 而且即時 (real time) 的多媒體資料播放品質。

在多方多媒體播放架構中，為了實現群體多媒體資料即時廣播通訊的目的，多方多媒體伺服器中設計了三層軟體系統架構，分別為多媒體資料同步層、群體廣播控制層、以及網路傳輸控制層。在終端多媒體播放電腦 (client) 端，則設計了四層軟體系統架構﹐分別為使用者介面層、多媒體資料同步層、群體廣播控制層、以及網路傳輸控制層等。

在本篇論文的其餘部份，我們將在第2節詳細介紹群體廣播在網際網路上的定義，原理及功能，這其中會包括RFC1112，IGMP，DVMRP，以及MOSPF。在第3節中，我們針對在廣域網路上執行群體多媒體播放的功能，而提出了一個稱作多方多媒體網路架構 (Multiparty Multimedia Network Architecture)，以及多方多媒體播放系統 (Multiparty Multimedia Presentation System)，可以滿足多方通話的需求。在第4節則對本論文作一總結。

2. Multicast Operations 

在網際網路上的資料傳輸方式有三種 [15], 單一傳播 (unicast), 廣播 (broadcast), 及群體廣播 (multicast)。 現茲分述如下:


單一傳播 (unicast) 係指資料傳輸的目的節點 (destination node) 只有一個。現有一般的網路應用, 大部份採用此種方式來傳送其資料. 


廣播 (broadcast) 係將資料傳輸到指定的目的網路上, 而在目的網路上的所有節點皆為目的節點。以IP地址格式 (address format) 而言, 基本上位元 (bit) 皆1時，表示執行廣播動作，而且廣播分為四種方式。 


有限廣播 (Limited Broadcast):只有目前所在的區域網路 (LAN) 上作廣播，其IP的地址格式為255.255.255.255。 


網路取向廣播 (Net-directed Broadcast):在某特定 (指定) 的網路作廣播，例如向某一類別為A (Class A) 的網路廣播，其IP地址格式為netid.255.255.255。 


子網路取向廣播 (Subnet-directed Broadcast):針對某等級(class) 中的某子網路 (Subnetwork) 作廣播。以類別B的網路來看，若其子網路遮罩 (subnet mask) 為255.255.255.0，而IP地址為140.116.46.255，則是表示將資料廣播到類別B的網路140.116.中的子網路46上，而最後一個255則是代表廣播的意思。 


全子網路取向廣播 (All-subnets-directed Broadcast):針對某一等級中所有的子網路皆作廣播。此種廣播方式必須與路由器 (router) 的子網路遮罩配合。例如有一類別B的子網路遮罩為255.255.255.0，則若有一IP地址為140.116.255.255時，則表示將資料廣播到類別B的網路140.116中的所有子網路上。在實際的網路架構中，歸屬於某一類別網路的所有子網路，可能位在不同路由器 (router) 的不同輸出入埠上(port)，因此藉由子網路遮罩，路由器可以將資料傳送到所屬的所有子網路上進行廣播 [15] 。 


群體廣播 (multicast) 則是將資料傳送給某一特定群體 (Group) 的所有成員 (members)，而屬於同一群體的各個成員可能是散佈在各個不同的網路上。在RFC1112 [2]這份文件中，定義了三種等級 (levels) 的IP群體廣播方式。 



　


等級0 (level 0):成員 (host) 無法執行收、送群體廣播資料。 


等級1 (level 1):成員只能執行收取群廣播資料。 


等級2 (level 2):成員可以執行收取及傳送群體廣播資料。 

在網際網路協定 (Internet Protocol) 中，將群體廣播定為類別D (class D)，其格式如圖1所示，而每一個群體 (Group) 都有一個唯一的multicast group ID代表其地址，其範圍為244.0.0.0～239.255.255.255，其中224.0.0.0～224.0.0.255僅用在區域網路 (local network) 上。另外有些群體地址是固定而專用的，例如224.0.0.1代表在此子網路上的所有系統 (system) 皆為群體的成員，又如224.0.0.2代表"在此子網路上的所有路由器 (routers) 皆是群體成員"。在乙太網路 (Ethernet) 所用的地址中，也制定群體廣播專用的地址，而其格式與IP層的群體地址有相對應的關係。乙太網路的群體地址格式與IP層的群體地址對應關係則如圖2所示:



　

其中region A表示在IP群體址中的後面23個位元 (bits) 必須拷貝 (copy) 到乙太網路地址的後面的23個位元上; 而region B則表示在IP群體地址中的前五個位元 (bits) 不對應到乙太地址上。另外乙太網路地址的前24個位元固定為01:00:5e (以16進制表示)，而第25個位元固定為0。在乙太網路地址中訂定群體廣播地址的目的，在於加快群體廣播的速度，在資料連結層 (data-link layer) 即可判斷此資料是否為所屬的群體資料，若不是，則在資料連結層即可放棄該筆資料; 若是，則往上送到網際網路層 (IP layer)。但由於可以有32個multicast group IDs對應到同一個乙太網路地址，因此在網際網路層 (IP layer) 必須再作一次過濾 (filtering)，以確定是否為所屬的群體資料。

　

在網際網路中對於群體成員的管理，係利用群體管理協定 (Internet Group Management Protocol; IGMP) [15]。IGMP屬於IP層，制定IGMP有2個目的:(1)管理群體成員的加入 (join) 或離開 (leave)。(2)可以使群體路由器 (Multicast router, Mrouter) 知道群體的各個成員位在那些網路上。IGMP的message format如圖3與圖4:



　



　

其中:


IGMP version: 通常為1。 


IGMP Type: 指IGMP的封包種類有 


代表由群體廣播路由器 (Multicast Router, Mrouter) 送出的詢問 (query)，而此時之group address為0。 


代表由host送出之回應 (response)，亦可稱為IGMP report, 即回應本身所屬之群體地址 (the group address), 並可以用來向群體廣播路由器 (Mrouter) 註冊用。 

群體成員的加入 (join) 或離開 (leave) 皆為動態式的 (dynamic)，意即可以隨時加入或離開。

　

對群體路由器而言，在找尋路由路徑時，則可以採用距離向量群體廣播路由協定 (Distance Vector Multicast Routing Protocol, DVMRP) [16]，或是採用群體廣播開放最短路徑協定 (Multicast Open Shortest Path First protocol, MOSPF) [12]。距離向量群體廣播路由協定 (DVMRP) 係在建立Mrouters間之通道 (tunnels)，而群體廣播資料封包在跨越網際網路時，則是利用預先在各Mrouters之間所建立好的通道 (tunnel)。通道 (tunnels) 是一條虛擬 (virtual) 的點對點 (point-to-point) 網路連線 (link)，負責傳送各個Island間的群體廣播資料封包。在每一通道 (tunnel) 上都有一個metric值以及一個基準值 (threshold value)。Metric值在定義路由 (routing) 此通道 (tunnel) 時的花費 (cost)，用以反應此通道 (tunnel) 的資料流量 (traffic) 狀態。而基準值 (threshold value) 則用在當群體廣播資料封包上的生命週期值 (Time To Live, TTL) 大於Mrouter上的基準值時，此封包方允許可以經由通道 (tunnel) 被送往另一個Mrouter上，而且每作一次Mrouter跳躍時，則生命週期值 (TTL) 就減一，此作法可以控制群體廣播資料封包的適度擴散，以節省網路頻寬(bandwidth)。另外距離向量群體廣播路由協定利用各條通道上的metric值，計算出總合最小的路由路徑 (routing path) 出來，以利群體廣播資料封包的傳送。而群體廣播開放最短路徑協定 (MOSPF) 係利用Dijkstra演算法並採即需求 (on-demand) 的方式來計算出傳輸的最短路徑，不再使用通道 (tunnels)裝置，因此Mrouter不用再需要複製想要傳送的群體廣播資料封包，以增加效能 (performance)，至於其詳細的距離向量群體廣播路由協定與群體廣播開放最短路徑協定運作則參考 [12,16]。

　

3. Multicast Multimedia Network Architecture and System

　

欲完成一個多媒體播放系統所必須面對的主要課題有(1)多媒體群體廣播網路架構的設計，(2)多媒體群體廣播網路系統的設計與實作，(3)以及多媒體群體廣播網路協定的設計與建立。其中第3項已於前一節有所討論，現在分述第1、2項如下。

　


多媒體群體廣播網路架構的設計 : 

根據已經定義的網際網路群體廣播地址 (Class D)，網際網路群體管理協定 (IGMP)，以及距離向量群體廣播路由協定 (DVMPR)，與群體廣播開放最短路徑協定 (MOSPF)，我們可以設計出一個二階層之階層式多方多媒體網路架構 (Multiparty Multimedia Networking Architecture)。如圖5-(a)所示，此二階層架構為end-to-end的通訊控制架構。圖5-(b)為其相對應於OSI七層架構的系統概念。

整個網路為各個區域網路經路由器 (router) 所串接而成。在每一個區域網路上，皆有一個多方多媒體伺服器 (Multiparty Multimedia Server)，以及連接在此區域網路上的一些終端多媒體播放電腦 (Multimedia Presentation Clients)。每一個多方多媒體伺服器儲存一些多媒體資料，當某一終端電腦C要求播放的多媒體資料是儲存在多方多媒體伺服器A時，則稱多方多媒體伺服器A為真伺服器 (Physical Server)，但可能終端電腦C所位在的區域網路其所屬的多方多媒體伺服器為B，則稱多方多媒體伺服器B為虛伺服器 (Virtual Server)。虛伺服器B (Virtual Server B) 自真伺服器A (Physical Server A) 接收到多媒體資料時，由於此多媒體資料經過網際網路的傳送，會產生不可預期的延遲 (unpredictable delay)，進而發生間差 (jitters) 與歪斜誤差(skews) 造成多媒體資料不能同步的問題 (synchronization problems)，因此虛伺服器B必須先解決多媒體資料同步的問題後，再群體廣播給位於自己管轄的區域網路上的終端電腦C。因此多方多媒體伺服器的功能必包括 (1) 多媒體資料儲存資料庫； (2) 多媒體資料的同步處理﹐以作好多媒體服務品質 (QoS) 之控制﹔(3) 群體成員 (member) 加入 (join)﹐與離開 (leave) 的管理﹔(4) 群體廣播 (multicast) 橫跨網路時﹐路由路徑 (routing path) 之決定與執行﹔(5) 允許控制(Admission Control) 之執行﹐在有限的網路頻寬 (bandwidth) 上控制多媒體資料之傳輸數目﹐以求較完善之多媒體播放 (presentation) 品質。至於多方多媒體伺服器的詳細運作功能與多媒體資料同步問題之解決，則參考 [5,6,7]。



　



　


多媒體群體廣播網路系統以及多媒體群體廣播網路協定的設計 : 

為了實現多媒體群體即時廣播播放的目的，我們提出一個多方多媒體播放系統 (Multiparty Multimedia Presentation System)﹐其作法是分別在多方多媒體伺服器以及終端多媒體播放電腦建立若干軟體系統。如圖6所示﹐在多方多媒體伺服器中設計了三層軟體系統架構﹐分別為多媒體資料同步層，群體廣播控制層，以及網路傳輸控制層。在終端多媒體播放電腦，則設計了四層軟體系統架構﹐分別為使用者介面層﹐多媒體資料同步層，群體廣播控制層，以及網路傳輸控制層等﹐其功能現茲分述如下。

　



　


多方多媒體伺服器系統: 

在每一個區域網路上，皆有一個多方多媒體伺服器系統﹐圖7為依據圖4的系統架構﹐再將多方多媒體伺服器系統細分為六部份，現分述其功能如下。



　


多媒體資料處理與同步層 : 

此層包括多媒體資料同步控制 (synchronization control)﹐允許控制 (admission control)﹐以及多媒體資料庫查詢三部份部份。多媒體資料庫查詢是在達成多媒體資料的搜尋與抓取，如果所要求播放的多媒體資料是儲存在目前的 (local) 多方多媒體伺服器時，由於區域網路的傳輸延遲較小，因此再配合以適當的允許控制 (admission control)，則多媒體資料可以不經由同步處理，而直接送到終端電腦。但是如果所要求播放的多媒體資料並非儲存在目前的 (local) 多方多媒體伺服器，而是儲存在遠端的 (remote) 多方多媒體伺服器時，則多媒體資料經廣域網路傳輸時，由於廣域網路的傳輸延遲 (delay) 難以控制，而造成多媒體資料的時間誤差，例如jitters以及 skews。因此若想達到即時 (real time) 而且符合服務品質要求(Quality of Service) 的多媒體資料傳輸，則必須採用同步的技術，以平順 (smooth) 終端電腦的多媒體播放。可以採用的多媒體資料同步策略很多 [5,6,14]，例如對於聲訊 (audio) 資料可以採用停滯同步策略 (blocking synchronization scheme)，這是針對人類的耳朵可以容忍聲音小時間的中斷，所採用的方法。另外目前的 (local) 多方多媒體伺服器與遠端的 (remote) 多方多媒體伺服器的控制方法，以及群體廣播下的多媒體資料同步機置的設計則於 [5,6,7] 有所討論。


群體廣播控制層 : 

此層包括IGMP﹐DVMRP﹐MOSPF﹐以及RFC1112四部份。此層所包括IGMP，DVMP，MOSPF﹐以及RFC 1112四種有關群體廣播協定的設計與實作。此四種協定中的RFC1112為群體廣播定址方式與功能的文件。而IGMP是在執行網際網路群體管理協定，以及管理某群體成員的加入或離開，並且記錄其各個成員的所在網路。而DVMP以及MOSPF則可以求出在網際網路上的最短群體廣播路徑，以供群體廣播控制使用。此層為執行群體廣播的功能並配合來自網路傳輸控制層得到的多媒體資料，再傳送給多媒體資料同步處理層作同步處理，或反之自多媒體資料同步處理層所得到已作同步處理的多媒體資料，再傳送給網路傳輸控制層。


網路傳輸控制層 : 

現行的網際網路為採用UDP/TCP IP網路傳輸協定，其中TCP可用於傳輸要求無誤 (error-free) 的靜止媒體 (static media)，例如文字 (text) 以及影像 (image) 資料等。UDP則可用於傳輸要求即時 (real time) 而允許少量錯誤的連續媒體 (continuous media)，例如視訊 (video) 以及聲訊 (audio) 資料等。而群體廣播 (multicast) 在網際網路上所使用的網路傳輸協定為使用者資料單元協定 (User Datagram Protocol, UDP)，UDP是不可靠 (unreliable) 而且不保證資料封包有順序 (sequence order) 的網路傳輸協定，因此在設計網路傳輸控制層時，必須加入適當的可靠度與資料封包順序控制，並且避免” 確認訊息接收破裂 (acknowledgment implosion) “的問題。因此Reliable&Sequence Control Protocol的設計在滿足即時 (real time) 的而且可以允許少數資料流失的網路傳輸協定。而另一方面﹐為了達到某些資料不可以因網路傳輸協定的關係而有所流失，因此必須有符合即時性與可靠度兩種特性﹐即具有QoS性質的網路傳輸協定，並且解決自廣域網路上所接收的資料時，所面臨網路延遲的變異性 (network delay variance) 較大的問題，並且完成流量控制以及封包順序的安排。

　


終端多媒體播放系統 : 

終端多媒體播放電腦除配備有麥克風、喇吧、音效卡等相關的硬體設備外﹐軟體系統如圖6所示﹐依所提供的功能而劃分成使用者介面層，多媒體資料同步層，群體廣播控制層，以及網路傳輸控制層等四層。圖8為依據圖6的系統架構﹐再將終端多媒體播放系統細分，現分述其功能如下。



　


使用者介面層: 依所需之應用而執行多媒體資料之介面程式。 


多媒體資料同步層: 目的在將多媒體資料以同步的方式播放出來，例如影像 (video) 資料與語音 (audio) 資料的lip synchronization.。並且由於方多媒體伺服器已經執行了多媒體資料的同步控制，因此在終端多媒體播放電腦端可以減少大量的多媒體資料同步控制負擔 (synchronization control load) 以及資源的需求 (例如buffers等)。 


群體廣播控制層 : 此層包括IGMP以及RFC1112二部份有關群體廣播協定的設計與實作。此二種協定中的IGMP是在執行網路群體管理協定屬於成員 (member) 端部份，以完成某群體成員的加入或離開的需求。而RFC1112為群體廣播定址方式與功能的文件。此層並配合來自多媒體資料同步層所得到的多媒體資料，再傳送給網路傳輸控制層﹐其目的在將自多方多媒體伺服器所傳送過來的群體多媒體資料，轉換成多媒體資料同步層所需要的格式後，送往多媒體資料同步層作播放。 


網路傳輸控制層: 此層執行Reliable&Sequence Control Protocol。Reliable&Sequence Control Protocol的設計﹐如A)之(3)所述﹐亦在滿足多媒體資料傳輸的特性，亦即必需具有QoS性質的網路傳輸協定﹐以解決自網際網路上所接收的資料時，所面臨網路延遲的變異性 (network delay variance) 較大的問題，並完成流量控制以及封包順序的安排。另外必須注意的是在終端部份的Reliable&Sequence Control Protocol時﹐其運作方式與伺服器端 (Server) 的Reliable&Sequence Control Protocol是有所區別的﹐例如必須考慮主﹑從 (Master and Slave) 的關係。 

　

4. Conclusion 

網路與多媒體是目前應用最為廣泛的系統，兩者結合可以提供給使用者各式各樣的應用服務，其中利用網路來達到即時的多媒體播放傳送的功能，並且可以多方播放傳送，勢必可以為人類生活帶來相當的效益。例如，一群分散在全球各地的會議參與者，可以藉廣域網路將其聲音、影像與會議資料同時、同步地播放出來，以達到互相討論的目的，而且不必花費巨額的國際差旅費用，以及為赴開會地點所付出的時間。

在本文中我們提出了一個可行的多方多媒體播放網路架構與系統，其中說明了如何達到群體多媒體資料廣播的功能，以及針對多媒體資料播放時所要求的服務品質 (QoS)，加入一個解決的機置 (mechanism)，以達到較為平順的多媒體資料播放品質。

junlinjd的这篇文章不错,有参考性,不过看上去好像是一篇毕业论文.若作为一个中小型企业要想实现多播的话,可以实现吗?
   我真心希望大家来共同探讨这个问题!

gz

广域网中不能多播吧？如果能得话，岂不乱套了，大家的数据可以到处乱发！
-------------------------------------------------------------------
multicast!=broadcast

多播是客户端同意要了才可以的。
更本不回降低网络性能，反而能够促进网络性能。