igmp(internet組管理協(xié)議)報(bào)文及協(xié)議-資料下載頁
2025-07-25 11:15本頁面
【正文】 進(jìn)行多播，所以我們在該以太網(wǎng)中的其他系統(tǒng)中也能觀察到它們。在啟動(dòng)選路守護(hù)程序之前，圖135顯示了輸出的結(jié)果。在這個(gè)輸出中沒有包括以太網(wǎng)地址，因?yàn)橐呀?jīng)證實(shí)了它們是正確的。也刪去了TTL等于1的說明，同樣因?yàn)樗鼈円彩俏覀兤谕哪菢?。?dāng)選路守護(hù)程序啟動(dòng)時(shí)，輸出第1行。，它被當(dāng)前用于多播選路的距離向量多播選路協(xié)議DVMRP(Distance Vector Multicast Routing Protocol)所使用（DVMRP在RFC 1075中定義[Waitzman ,Partridge, and Deering]）。在該守護(hù)程序啟動(dòng)時(shí)，它也發(fā)送一個(gè)IGMP查詢（第2行）。（所有主機(jī)組），如圖133所示。第一個(gè)報(bào)告（第3行）大約在5秒后收到。這是在下一個(gè)查詢發(fā)出之前（第4行）收到的唯一報(bào)告。當(dāng)守護(hù)程序啟動(dòng)后，兩次查詢（第2行和第4行）發(fā)出的間隔很短，這是因?yàn)槭刈o(hù)程序要將其多播路由表盡快建立起來。第6和7行正是我們期望看到的：sun主機(jī)針對它所屬的每個(gè)組發(fā)出一個(gè)報(bào)告。，而其他兩個(gè)組則是明確加入的，因?yàn)橹灰x路守護(hù)程序還在運(yùn)行。下一個(gè)查詢位于第8行，大約在前一個(gè)查詢的2分鐘后發(fā)出。它再次引發(fā)三個(gè)我們所期望的報(bào)告（第10和11行）。這些報(bào)告的時(shí)間順序與前面不同，因?yàn)榻邮詹樵兒桶l(fā)送報(bào)告的時(shí)間是隨機(jī)的。最后的查詢在前一個(gè)查詢的大約2分鐘后發(fā)出，我們再次得到了期望的響應(yīng)。多播是一種將報(bào)文發(fā)往多個(gè)接收者的通信方式。在許多應(yīng)用中，它比廣播更好，因?yàn)槎嗖ソ档土瞬粎⑴c通信的主機(jī)的負(fù)擔(dān)。簡單的主機(jī)成員報(bào)告協(xié)議( IGMP )是多播的基本模塊。在一個(gè)局域網(wǎng)中或跨越鄰近局域網(wǎng)的多播需要使用本章介紹的技術(shù)。廣播通常局限在單個(gè)局域網(wǎng)中，對目前許多使用廣播的應(yīng)用來說，可采用多播來替代廣播。然而，多播還未解決的一個(gè)問題是在廣域網(wǎng)內(nèi)的多播。[Deering and Cheriton 1990] 提出擴(kuò)展目前的路由協(xié)議來支持多播。[Perlman 1992]討論了廣域網(wǎng)多播的一些問題。[Casner and Deering 1992] 介紹了使用多播和一個(gè)稱為MBONE（多播主干）的虛擬網(wǎng)絡(luò)在整個(gè)Internet上傳送IETF會議的情況。
教學(xué)教案相關(guān)推薦
鄂ICP備17016276號-1