《Java網(wǎng)絡程序設計》課件-第6章

第6章UDPSocket

6.1UDP6.2UDPSocket6.3IP廣播6.4IP組播

6.1UDP

6.1.1UDP的概念

UDP是TCP/IP參考模型中傳輸層的無連接協(xié)議，提供面向事務的、簡單的、不可靠的數(shù)據(jù)傳送服務。UDP協(xié)議的最早規(guī)范于1980年發(fā)布，編號為RFC768。UDP與TCP均屬于TCP/IP體系結(jié)構(gòu)中傳輸層的協(xié)議，通過應用層與傳輸層之間的端口為上層的應用程序提供并發(fā)傳輸服務。雖然UDP是一種不可靠的網(wǎng)絡協(xié)議，但是在很多情況下UDP協(xié)議會非常有用。因為UDP具有TCP所望塵莫及的數(shù)據(jù)傳輸速度優(yōu)勢。在TCP協(xié)議中植入了各種安全保障功能，但是在實際執(zhí)行的過程中會占用大量的系統(tǒng)開銷，使TCP傳輸速度受到了嚴重的影響。反觀UDP，由于排除了信息可靠傳遞機制，將安全和排序等功能移交給上層應用來完成，極大降低了執(zhí)行時間，使數(shù)據(jù)傳輸速度得到了保證。UDP與TCP之間的主要區(qū)別如表6-1所示。正因為UDP的特點，在為網(wǎng)絡通信軟件選擇使用協(xié)議的時候，選擇UDP必須要謹慎。在網(wǎng)絡質(zhì)量令人不十分滿意的環(huán)境下，UDP協(xié)議數(shù)據(jù)包丟失會比較嚴重，很多僅在局域網(wǎng)環(huán)境下使用的通信軟件采用UDP協(xié)議。又由于UDP不屬于連接型協(xié)議，具有資源消耗小、處理速度快的優(yōu)點，因而通常音頻、視頻和消息數(shù)據(jù)在傳送時使用UDP較多，因為它們即使偶爾丟失一兩個數(shù)據(jù)包，也不會對接收結(jié)果產(chǎn)生太大影響。比如各種類型的聊天室軟件，如ICQ、QQ和視頻電話會議系統(tǒng)均使用的UDP協(xié)議。相對于數(shù)據(jù)傳輸?shù)目煽啃远?，某些應用更加注重實際性能，為了獲得更好的使用效果(例如，更高的畫面幀刷新速率)，往往可以犧牲一定的可靠性(例如，畫面質(zhì)量)。采用UDP應用層的協(xié)議如表6-2所示。6.1.2信息傳播的形式

信息在網(wǎng)絡中傳播的形式有三種，分別是：單播(UniCast)、廣播(BroadCast)和組播(MultiCast，或稱為多播)，如圖6-1所示。采用TCP作為傳輸協(xié)議，信息傳遞只能實現(xiàn)點到點的單播形式，如果必須使用TCP作為傳輸協(xié)議而實現(xiàn)向多個用戶發(fā)送相同的消息，就必須采用輪流循環(huán)的方式進行點到點的單播，從而降低了信息的實時性也浪費了帶寬。利用UDP作為傳輸協(xié)議，則可以實現(xiàn)所有形式的傳播。圖6-1單播、廣播、組播示意圖單播指客戶端與服務器之間的點到點連接，即當客戶端發(fā)出請求時，服務器發(fā)送獨立單播流。單播的優(yōu)點：服務器及時響應客戶機的請求；服務器針對每個客戶不同的請求發(fā)送不同的數(shù)據(jù)，容易實現(xiàn)個性化服務。單播的缺點：服務器針對每個客戶機都需要發(fā)送數(shù)據(jù)流，服務器流量?=?客戶機數(shù)量?×?客戶機流量；在客戶數(shù)量大、每個客戶機流量大的流媒體應用中服務器不堪重負?，F(xiàn)有的網(wǎng)絡帶寬是金字塔結(jié)構(gòu)，即城際省際主干帶寬僅僅相當于其所有用戶帶寬之和的5％。如果全部使用單播協(xié)議，將造成網(wǎng)絡主干不堪重負。現(xiàn)在的P2P應用就已經(jīng)使主干經(jīng)常阻塞，只要5％的客戶在全速使用網(wǎng)絡，其他人就無法使用了，而將主干擴展20倍幾乎是不可能的。廣播指主機之間“一對所有”的通信模式，網(wǎng)絡對其中每一臺主機發(fā)出的信號都進行無條件復制并轉(zhuǎn)發(fā)，所有主機都可以接收到所有信息(不管是否需要)，由于其不用路徑選擇，所以其網(wǎng)絡成本可以很低廉。廣播的優(yōu)點：網(wǎng)絡設備簡單，維護簡單，布網(wǎng)成本低廉；由于服務器不用向每個客戶機單獨發(fā)送數(shù)據(jù)，所以服務器流量負載極低。廣播的缺點：無法針對每個客戶的要求和時間及時提供個性化服務；網(wǎng)絡允許服務器提供數(shù)據(jù)的帶寬有限，客戶端的最大帶寬＝服務總帶寬。例如有線電視的客戶端的線路支持100個頻道(如果采用數(shù)字壓縮技術(shù)，理論上可以提供500個頻道)，即使服務商有更大的財力配置更多的發(fā)送設備、改成光纖主干，也無法超過此極限。也就是說廣播無法向眾多客戶提供更多樣化、更加個性化的服務；廣播禁止在Internet寬帶網(wǎng)上傳輸，因為會產(chǎn)生廣播風暴，造成網(wǎng)絡阻塞。組播指主機之間“一對一組”的通信模式，也就是加入了同一個組的主機可以接收到此組內(nèi)的所有數(shù)據(jù)，網(wǎng)絡中的交換機和路由器只向有需求者復制并轉(zhuǎn)發(fā)其所需數(shù)據(jù)。組播的優(yōu)點：需要相同數(shù)據(jù)流的客戶端加入相同的組共享一條數(shù)據(jù)流，節(jié)省了服務器的負載，具備廣播所具備的優(yōu)點；由于組播協(xié)議是根據(jù)接收者的需要對數(shù)據(jù)流進行復制轉(zhuǎn)發(fā)，所以服務端的服務總帶寬不受客戶接入端帶寬的限制。IP協(xié)議允許有2億6千多萬個組播，所以其提供的服務可以非常豐富；此協(xié)議和單播協(xié)議一樣允許在Internet寬帶網(wǎng)上傳輸。組播的缺點：與單播協(xié)議相比沒有糾錯機制，發(fā)生丟包錯包后難以彌補，但可以通過一定的容錯機制和QoS加以彌補?，F(xiàn)行網(wǎng)絡雖然都支持組播的傳輸，但在客戶認證、QoS等方面還需要完善，這些缺點在理論上都有成熟的解決方案，只是需要逐步推廣應用到現(xiàn)存網(wǎng)絡當中。

6.2UDPSocket

6.2.1DatagramSocket類和DatagramPacket類

在J2SDK以前的版本里，TCP和UDP套接字都使用Socket類。在J2SDK中專門提供了UDP的套接字類，在類庫中有DatagramSocket類和DatagramPacket類來實現(xiàn)對UDP數(shù)據(jù)報的傳輸。

DatagramSocket類用于實現(xiàn)UDP通信的套接字，實現(xiàn)端到端的通信，完成數(shù)據(jù)報的接收和發(fā)送。其特點是數(shù)據(jù)發(fā)送端和接收端不需要事先建立通信連接，甚至可以是在接收端未準備好或者不存在的情況下，發(fā)送端也可以進行消息發(fā)送，類定義如圖6-2所示。圖6-2DatagramSocket類定義其構(gòu)造方法有：

●?publicDatagramSocket()，在本地系統(tǒng)任一空閑的UDP端口建立UDPSocket對象；

●?publicDatagramSocket(intport)，在指定端口建立UDPSocket對象；

●?publicDatagramSocket(intport,InetAddressaddress)，在指定InetAddress對象和端口建立UDPSocket對象。

其主要方法有：

●?publicvoidsend(DatagramPacketsp)throwsIOException，發(fā)送一個數(shù)據(jù)報；

●?publicsynchronizedvoidreceive(DatagramPacketrp)throwsIOException，接收一個數(shù)據(jù)報；

●?publicvoidclose()，關(guān)閉當前UDP套接字。代碼說明如下：

①第5行聲明一個DatagramSocket對象；

②第6～15行循環(huán)測試指定的UDP端口范圍；

③第8行在指定的UDP端口建立一個UDP套接字，如果成功則說明該端口空閑，否則說明該端口已被占用。

運行結(jié)果如圖6-3所示。

DatagramPacket類是構(gòu)造一個用于接收或者發(fā)送的數(shù)據(jù)報，采用字節(jié)數(shù)組的形式存儲數(shù)據(jù)，類定義如圖6-4所示。圖6-3掃描本地UDP端口圖6-4DatagramPacket類定義其提供的構(gòu)造方法：

●?publicDatagramPacket(bytebuf[],intlength)：該構(gòu)造方法中包括了用于存儲數(shù)據(jù)的字節(jié)數(shù)組和可存儲的字節(jié)數(shù)，主要用于接收數(shù)據(jù)報；

●?publicDatagramPacket(bytebuf[],intlength,InetAddressaddress,intport)：該構(gòu)造方法中包括存儲數(shù)據(jù)的字節(jié)數(shù)組、可存儲的字節(jié)數(shù)、接收端的地址，以及接收端的端口號，通常被用于發(fā)送數(shù)據(jù)報。其主要方法：

●?publicsynchronizedgetDate()：從數(shù)據(jù)報中獲得數(shù)據(jù)；

●?publicsynchronizedgetLength()：從數(shù)據(jù)報中獲得數(shù)據(jù)長度；

●?publicsynchronizedsetDate(bytebuf[])：設置數(shù)據(jù)報的數(shù)據(jù)；

●?publicsynchronizedsetLength(intlength)：設置數(shù)據(jù)報的長度。

使用UDP實現(xiàn)通信，需要分別建立通信的發(fā)送端和接收端程序。

代碼說明如下：

①第4行創(chuàng)建UDP套接字對象；

②第5行創(chuàng)建UDP數(shù)據(jù)報對象；

③第6行創(chuàng)建數(shù)據(jù)接收方的InetAddress對象；

④第7行定義數(shù)據(jù)接收方的端口號；

⑤第8行定義發(fā)送和接收緩存字節(jié)數(shù)組,容量為256B；

⑥第9～16行啟動本地的UDP1080端口；

⑦第19行創(chuàng)建接收數(shù)據(jù)報對象，綁定接收字節(jié)數(shù)組長度為256；

⑧第20行執(zhí)行receive()方法接收數(shù)據(jù)；⑨第21行通過getData()方法從收到的數(shù)據(jù)報中提取數(shù)據(jù)；

⑩第23～25行提取收到的數(shù)據(jù)報中的對方IP和端口信息；

?第26～27行首先通過getBytes()方法將字符串轉(zhuǎn)換為字節(jié)數(shù)組，然后再構(gòu)造發(fā)送數(shù)據(jù)報，在參數(shù)中指明接收方的IP和PORT，這個地址信息從第23～24行獲得；

?第28行使用send()將數(shù)據(jù)報發(fā)送出去。

運行結(jié)果如圖6-5所示。圖6-5接收端運行結(jié)果在接收端首先建立接收緩存，使用定義字節(jié)數(shù)組，該數(shù)組的尺寸通常為8的整數(shù)倍，例如256，512，1024，2048等；將該字節(jié)數(shù)組帶入DatagramPacket構(gòu)造接收數(shù)據(jù)報；通過DatagramSocket.receive()接收數(shù)據(jù)報；利用DatagramPacket.getData()方法從數(shù)據(jù)報中提取出字節(jié)數(shù)組，并且將字節(jié)數(shù)組作為String的參數(shù)構(gòu)造可讀的字符串。

從運行結(jié)果中，可以得到發(fā)送端的IP地址是，使用的UDP端口是1065，接收的信息是“從發(fā)送端發(fā)送信息”。

代碼注釋如下：

①第11行本地開啟UDP1065端口；

②第19～23行構(gòu)造發(fā)送數(shù)據(jù)報，并通過send()發(fā)送該數(shù)據(jù)報；

③第25～26行構(gòu)造接收數(shù)據(jù)報，并通過receive()接收數(shù)據(jù)報。

運行結(jié)果如圖6-6所示。圖6-6發(fā)送端運行結(jié)果在發(fā)送端首先構(gòu)造發(fā)送緩存，采用字節(jié)數(shù)組，該數(shù)組尺寸同接收緩存；如果要發(fā)送字符串信息，需要使用String.getBytes()將待發(fā)送的字符串轉(zhuǎn)化為字節(jié)數(shù)組；將字節(jié)數(shù)組作為DatagramPacket對象的參數(shù)構(gòu)造發(fā)送數(shù)據(jù)報；通過DatagramSocket.send()方法將數(shù)據(jù)報發(fā)送出去。

從運行結(jié)果中，可以得到接收端的IP地址是，使用的UDP端口是1080，發(fā)送端得到的信息是“從接收端返回確認”。

當一個客戶端同時接收和發(fā)送信息時，要注意發(fā)送和接收緩沖一定要區(qū)分開，并且在每次接收或者發(fā)送之前，要清除原有內(nèi)容，否則會殘留不必要的信息。6.2.2TCPSocket與UDPSocket的區(qū)別

TCP和UDP兩種傳輸協(xié)議都在網(wǎng)絡世界中發(fā)揮重要的作用。應用層進程根據(jù)不同網(wǎng)絡通信的環(huán)境和特點，實際網(wǎng)絡通信軟件設計需要在UDP和TCP兩種協(xié)議之間權(quán)衡。在Java中進行編程時，有以下區(qū)別：

1．消息傳遞的形式

TCP是面向連接的服務，只能實現(xiàn)點到點的傳遞。

UDP可以實現(xiàn)單播、廣播和多播。在實現(xiàn)廣播時，數(shù)據(jù)報目的地址為指定網(wǎng)絡中最大的IP地址，例如55，具體由網(wǎng)絡規(guī)劃情況而定。在實現(xiàn)多播時，數(shù)據(jù)報目的地址為D類地址。

2．所使用的Socket

在TCP傳輸模式下，使用ServerSocket用于監(jiān)聽指定端口，保證實現(xiàn)TCP的三次握手；使用Socket建立通信的通道。

在UDP傳輸模式下，使用DatagramSocket直接實現(xiàn)傳輸消息的包。

3．Socket定義的位置不同

在TCP模式下，由于存在三次握手、傳輸、關(guān)閉等多個階段，所以Socket定義應該為類的屬性，便于在所有的方式中進行操作。

在UDP模式下，是盡最大可能交付，并不需要事先建立連接，屬于單傳輸階段的形式，所以在發(fā)送數(shù)據(jù)通信的類中進行定義即可，表現(xiàn)為在響應發(fā)送按鈕事件處理和接收數(shù)據(jù)的事件處理方法中的局部變量。

4．是否存在監(jiān)聽及方式

在TCP模式下，存在三次握手機制，利用ServerSocket持續(xù)監(jiān)聽指定端口是否有連接請求到達。

在UDP模式下，直接從指定端口發(fā)送或接收數(shù)據(jù)。

5．輸入/輸出流的定義

在TCP模式下，由于屬于管道類型的流操作，所以利用Socket.getInputStream()和Socket.getOutputStream()，分別從指定的Socket上獲得輸入和輸出流。

在UDP模式下，按數(shù)據(jù)報文的形式進行數(shù)據(jù)通信，不存在輸入/輸出流。

6．發(fā)送數(shù)據(jù)的方式

在TCP模式下，首先定義輸出流，在該輸出流的基礎(chǔ)上直接發(fā)送字符串：

DataOutputSrteamos=newDataOutputStream(Socket.get

OutputStream());

os.writeUTF(“Hello!”);

os.flush();

在UDP模式下，創(chuàng)建待發(fā)送的數(shù)據(jù)包二進制數(shù)組，打包為UDP數(shù)據(jù)包，通過send發(fā)送指定數(shù)據(jù)包：

buf=“Hello”.getBytes();

p=newDatagramPacket(buf,buf.length,address,1080);

socket.send(p);

7．接收數(shù)據(jù)的方式

在TCP模式下，首先生成輸入流，然后按行的方式進行讀?。?/p>

DataInputStreamin=newDataInputStream(clientSocket.getInputStream());

inputLine=in.readUTF()

在UDP模式下，首先生成接收數(shù)據(jù)的UDP緩存數(shù)組，然后利用receive方法，接收數(shù)據(jù)到指定的緩存中：

p=newDatagramPacket(buf,buf.length);

socket.receive(p);

通常，TCP協(xié)議被用于有傳輸可靠性要求的應用，UDP被廣泛用于局域網(wǎng)傳輸和傳輸數(shù)據(jù)實時性要求高的應用中。

6.3IP廣播

UDP允許對指定的網(wǎng)絡發(fā)送廣播消息。途徑是通過將數(shù)據(jù)報發(fā)送到該網(wǎng)絡廣播地址上實現(xiàn)。廣播地址的計算與主機上網(wǎng)卡配置的IP地址和網(wǎng)絡掩碼有關(guān)，如使用ifconfig.exe顯示目標計算機的網(wǎng)卡IP配置信息如圖6-7所示。圖6-7網(wǎng)卡配置信息從圖6-7中得到主機的IP地址是4，其子網(wǎng)掩碼是，默認的出口網(wǎng)關(guān)是54。

對于常規(guī)的A，B，C三類IP分類方法，獲得廣播地址很容易。一個IP地址包括網(wǎng)絡號和主機號兩個部分，共24位。當主機地址全為“0”時表示該主機所處的網(wǎng)絡地址，當主機地址全為“1”時表示為指定網(wǎng)絡的廣播地址。通過IP地址與網(wǎng)絡掩碼進行按位與運算，可以得到該主機所處網(wǎng)絡號為：，則廣播地址為55，如圖6-8所示。圖6-8IP地址與子網(wǎng)掩碼按位與運算得到網(wǎng)絡號當網(wǎng)絡管理員在局域網(wǎng)中劃分了子網(wǎng)時，則在A、B、C分類的基礎(chǔ)上，將主機位數(shù)再次劃分為子網(wǎng)號和主機號兩個部分。例如：IP地址是4，而子網(wǎng)掩碼是92，即IP地址中第四段的最高兩位被用于標識子網(wǎng)。這時該IP地址所處的網(wǎng)絡號為，但是廣播地址是3。

如果在IP地址分配時采用了CIDR的分配方法，則網(wǎng)絡號和廣播地址的計算都需要注意。例如IP地址是4/28，標識一共使用了28位作為網(wǎng)絡號，而剩余的4位作為主機號，則該主機所處的網(wǎng)絡號為6，廣播地址是1。

【例6-4】

使用UDP向一個廣播地址發(fā)送數(shù)據(jù)。該例與例6-3的唯一差別在于所使用的目標地址為網(wǎng)絡地址，而例6-3中的目標地址為主機地址。

代碼注釋如下：第19行構(gòu)造目標計算機所在的網(wǎng)絡地址(55)的InetAddress對象。這時接收客戶端就可以同時接收單播信息和本網(wǎng)絡中的廣播信息，如圖6-9所示。圖6-9接收端同時接收單播和廣播信息通用的廣播地址是55。在選擇廣播地址時，首先要根據(jù)所提供的子網(wǎng)掩碼判斷該IP地址是采用哪一種的IP劃分方式，否則就可能計算廣播地址錯誤，導致將數(shù)據(jù)報發(fā)送給了錯誤的網(wǎng)絡。

6.4IP組播

6.4.1組播的概念

TCP協(xié)議屬于面向連接的點到點通信，在服務器同時連接多個客戶端時，需要采用消息循環(huán)發(fā)送的形式，不僅增加了消息的延遲，而且還浪費了網(wǎng)絡帶寬。而UDP不僅可以實現(xiàn)消息的單播和廣播，還可以實現(xiàn)消息的組播。

IP組播(IPmulticasting)技術(shù)，也稱多址廣播或多播，是一種允許一臺或多臺主機作為多播源，發(fā)送單一數(shù)據(jù)包到多臺主機的TCP/IP網(wǎng)絡技術(shù)。多播作為一點對多點的通信，是節(jié)省網(wǎng)絡帶寬的有效方法之一。IP組播是對硬件組播的抽象，是對標準IP網(wǎng)絡層協(xié)議的擴展。它通過使用特定的IP組播地址，按照最大投遞的原則，將IP數(shù)據(jù)報傳輸?shù)揭粋€組播群組(Multicast

Group)的主機集合。在網(wǎng)絡音頻/視頻廣播的應用中，當需要將一個節(jié)點的信號傳送到多個節(jié)點時，無論是采用重復點對點通信方式，還是采用廣播方式，都會嚴重浪費網(wǎng)絡帶寬，只有多播才是最好的選擇。多播能使一個或多個多播源只把數(shù)據(jù)包發(fā)送給特定的多播組，而只有加入該多播組的主機才能接收到數(shù)據(jù)包。目前，IP多播技術(shù)被廣泛應用在網(wǎng)絡音頻/視頻廣播、音頻點播/視頻點播(AudioOnDemand/VideoOnDemand，AOD/VOD)、網(wǎng)絡視頻會議、多媒體遠程教育、“PUSH”技術(shù)(如股票行情等)和虛擬現(xiàn)實游戲等方面。要實現(xiàn)IP多播通信，要求介于多播源和接收者之間的路由器、集線器、交換機以及主機均需支持IP多播。目前，IP多播技術(shù)已得到硬件、軟件廠商的廣泛支持。

(1)要求主機支持IP多播通信的平臺包括Windows95以后的版本、Linux/Unix、Mactoshi等操作系統(tǒng)，運行這些操作系統(tǒng)的主機都可以進行IP多播通信。此外，新生產(chǎn)的網(wǎng)卡也幾乎都提供了對IP多播的支持。

(2)目前大多數(shù)集線器、交換機只是簡單地把多播數(shù)據(jù)當成廣播來發(fā)送接收，但一些中高檔交換機提供了對IP多播的支持。例如，在3COMSuperStack3Swith3300交換機上可啟用802.1p或IGMP多播過濾功能，只為已偵測到IGMP數(shù)據(jù)報的端口轉(zhuǎn)發(fā)多播數(shù)據(jù)報。

(3)多播通信要求多播源節(jié)點和目的節(jié)點之間的所有路由器必須提供對Internet組管理協(xié)議(InternetGroupManagementProtocol，IGMP)、多播路由協(xié)議(如PIM，DVMRP等)的支持。

由于得到硬件的支持，加入到一個多播組的主機，可以處于同一個局域網(wǎng)中，也可以是城域網(wǎng)或者廣域網(wǎng)中支持相同體系結(jié)構(gòu)的任一臺主機。使用同一個IP多播地址接收多播數(shù)據(jù)報的所有主機構(gòu)成了一個主機組，稱為多播組，如圖6-10所示。圖6-10多播組當一臺主機欲加入某個多播組時，會發(fā)出“主機成員報告”的IGMP消息通知多播路由器。當多播路由器接收到發(fā)給那個多播組的數(shù)據(jù)時，便會將其轉(zhuǎn)發(fā)給所有的多播主機。多播路由器還會周期性地發(fā)出“主機成員查詢”的IGMP消息，向子網(wǎng)查詢多播主機，若發(fā)現(xiàn)某個多播組已沒有任何成員，則停止轉(zhuǎn)發(fā)該多播組的數(shù)據(jù)。此外，當支持IGMPv2的主機退出某個多播組時，還會向路由器發(fā)送一條“離開組”的IGMP消息，以通知路由器停止轉(zhuǎn)發(fā)該多播組的數(shù)據(jù)。但只有當子網(wǎng)上所有主機都退出某個多播組時，路由器才會停止向該子網(wǎng)轉(zhuǎn)發(fā)該多播組的數(shù)據(jù)。

一個多播組的成員是隨時變動的，一臺主機可以隨時加入或離開多播組，多播組成員的數(shù)目和所在的地理位置也不受限制，一臺主機也可以屬于幾個多播組。此外，不屬于某一個多播組的主機也可以向該多播組發(fā)送數(shù)據(jù)報。6.4.2組播地址

IPv4地址可劃分為A、B、C、D、E和一些特殊的地址，如第4章表4-1所示。

現(xiàn)在由于計算機數(shù)量急劇增加，IPv4地址已經(jīng)不夠分配，所以逐漸放棄了IP地址的A，B，C分類法，采用劃分子網(wǎng)和超網(wǎng)方式分配IP地址，但是D類地址保留了下來。

IP多播通信必須依賴于IP多播地址，在IPv4中它是一個D類IP地址。D類IP地址第一個字節(jié)以“1110”開始，范圍從～55。它是一個專門保留的地址，它并不指向特定的網(wǎng)絡，代表網(wǎng)絡中一臺虛擬的主機。D類IP地址的組成如圖6-11所示。圖6-11D類IP地址

D類IP地址并不是隨意被使用的，這個地址范圍被劃分為局部鏈接多播地址、預留多播地址和管理權(quán)限多播地址三類，如下：

●?局部鏈接多播地址范圍在～55，這是為路由協(xié)議和其他用途保留的地址，路由器并不轉(zhuǎn)發(fā)屬于此范圍的IP包，多用于在LAN中組播；

●?預留多播地址為～55，可用于全球范圍(如Internet)或網(wǎng)絡協(xié)議；

●?管理權(quán)限多播地址為～55，可供組織內(nèi)部使用，類似于私有IP地址，不能用于Internet，可用于限制多播范圍。6.4.3MulticastSocket類

在Java語言中，采用MulticastSocket類來實現(xiàn)組播套接字，其類定義如圖6-12所示。圖6-12MulticastSocket類定義其構(gòu)造方法：

●?publicMulticastSocket()throwsIOException：聲明一個空的對象。

●?publicMulticastSocket(intport)throwsIOException：啟動本地指定UDP端口。

其主要方法：

●?publicvoidjoinGroup(InetAddressmulticastAddress)throwsIOException：加入某個多播組；

●?publicvoidleaveGroup(InetAddressmulticastAddress)throwsIOException：?離開某個多播組；●?publicsynchronizedvoidsend(DatagramPacketp)throwsIOException：?向加入的多播組發(fā)送數(shù)據(jù)；

●?publicsynchronizedvoidreceive(DatagramPacketp)throwsIOException：?從加入的多播組接收數(shù)據(jù)。

在下面的組播通信實例中，發(fā)送消息和接收數(shù)據(jù)的客戶端都加入到組播組中，程序需要在例6-2和例6-3的基礎(chǔ)上進行修改。

代碼注釋如下：

①第4行設置組播地址為，該組播地址僅能在局域網(wǎng)中使用，路由器不轉(zhuǎn)發(fā)該地址組播數(shù)據(jù)，限制了數(shù)據(jù)傳播的范圍；

②第6行聲明一個MulticastSocket對象；

③第12行在指定端口啟動一個UDP端口組播套接字；

④第13行創(chuàng)建組播地址的InetAddress對象；

⑤第14行將本地創(chuàng)建的組播套接字加入到組播組中；

⑥第23～29行實現(xiàn)循環(huán)向組播組發(fā)送數(shù)據(jù)，值得注意的是即使發(fā)送端不屬于組播組也可以向任意組播組發(fā)送數(shù)據(jù)。

代碼注釋如下：①第4～6行聲明組播地址、組播端口和組播套接字；②第10～16行加入到組播組，只有參加組播組，接收方才能收到數(shù)據(jù)；③第19～28行從組播組中接收數(shù)據(jù)。運行結(jié)果如圖6-13