日本免费全黄少妇一区二区三区-高清无码一区二区三区四区-欧美中文字幕日韩在线观看-国产福利诱惑在线网站-国产中文字幕一区在线-亚洲欧美精品日韩一区-久久国产精品国产精品国产-国产精久久久久久一区二区三区-欧美亚洲国产精品久久久久

  1. 首頁(yè) > 云知道 > >

關(guān)于廣播的應(yīng)用

云知道

【關(guān)于廣播的應(yīng)用】廣播是怎樣傳送的？路由器及主機(jī)又如何處理廣播？很遺憾，這是難以回答的問(wèn)題，因?yàn)樗揽坑趶V播的類(lèi)型、應(yīng)用的類(lèi)型、TCP/IP實(shí)現(xiàn)方法以及有關(guān)路由器的配置 。
首先，應(yīng)用程序必須支持廣播 。假如執(zhí)行
sun%ping255.255.255.255
/usr/etc/ping:unknownhost255.255.255.255打算在本地電纜上進(jìn)行廣播 。但它無(wú)法進(jìn)行，原因在于該應(yīng)用程序（ping）中存在一個(gè)程序設(shè)計(jì)上的問(wèn)題 。大多數(shù)應(yīng)用程序收到點(diǎn)分十進(jìn)制的IP地址或主機(jī)名后，會(huì)調(diào)用函數(shù)inet_addr(3)來(lái)把它們轉(zhuǎn)化為32bit的二進(jìn)制IP地址 。假定要轉(zhuǎn)化的是一個(gè)主機(jī)名，假如轉(zhuǎn)化失敗，該庫(kù)函數(shù)將返回-1來(lái)表明存在某種差錯(cuò)（例如是字符而不是數(shù)字或串中有小數(shù)點(diǎn)） 。但本網(wǎng)廣播地址（255.255.255.255）也被當(dāng)作存在差錯(cuò)而返回-1 。大多數(shù)程序均假定接收到的字符串是主機(jī)名，然后查找DNS（第14章），失敗后輸出差錯(cuò)信息如“未知主機(jī)” 。
假如我們修復(fù)ping程序中這個(gè)欠缺，結(jié)果也并不總是令人滿(mǎn)足的 。在6個(gè)不同系統(tǒng)的測(cè)試中，僅有一個(gè)像預(yù)期的那樣產(chǎn)生了一個(gè)本網(wǎng)廣播數(shù)據(jù)報(bào) 。大多數(shù)則在路由表中查找IP地址255.255.255.255，而該地址被用作默認(rèn)路由器地址，因此向默認(rèn)路由器單播一個(gè)數(shù)據(jù)報(bào) 。最終該數(shù)據(jù)報(bào)被丟棄 。
指向子網(wǎng)的廣播是我們應(yīng)該使用的 。我們向測(cè)試網(wǎng)絡(luò)中IP地址為140.252.13.63的以太網(wǎng)發(fā)送數(shù)據(jù)報(bào)，并接收以太網(wǎng)中所有主機(jī)的應(yīng)答 。與子網(wǎng)廣播地址關(guān)聯(lián)的每個(gè)接口是用于命令ifconfig的值 。假如我們ping那個(gè)地址，預(yù)期的結(jié)果是：
IP通過(guò)目的地址（140.252.13.63）來(lái)確定，這是指向子網(wǎng)的廣播地址，然后向鏈路層的廣播地址發(fā)送該數(shù)據(jù)報(bào) 。在6.3節(jié)提到的這種廣播類(lèi)型的接收對(duì)象為局域網(wǎng)中包括發(fā)送主機(jī)在內(nèi)的所有主機(jī)，因此可以看到除了收到網(wǎng)內(nèi)其他主機(jī)的答復(fù)外，還收到來(lái)自發(fā)送主機(jī)（sun）的答復(fù) 。
在這個(gè)例子中，我們也顯示了執(zhí)行ping廣播地址前后ARP緩存的內(nèi)容 。這可以顯示廣播與ARP之間的相互作用 。執(zhí)行ping命令前ARP緩存是空的，而執(zhí)行后是滿(mǎn)的（也就是說(shuō)，對(duì)網(wǎng)內(nèi)其他每個(gè)響應(yīng)回顯請(qǐng)求的主機(jī)在ARP緩存中均有一個(gè)條目） 。我們提到的該以太網(wǎng)數(shù)據(jù)幀被傳送到鏈路層的廣播地址（0xffffffff）是如何發(fā)生的呢？由sun主機(jī)發(fā)送的數(shù)據(jù)幀不需要ARP 。
假如使用tcpdump來(lái)觀察ping的執(zhí)行過(guò)程，可以看到廣播數(shù)據(jù)幀的接收者在發(fā)送它的響應(yīng)之前，首先產(chǎn)生一個(gè)對(duì)sun主機(jī)的ARP請(qǐng)求，因?yàn)樗膽?yīng)答是單播的 。在4.5節(jié)我們介紹了一個(gè)ARP請(qǐng)求的接收者（該例中是sun）通常在發(fā)送ARP應(yīng)答外，還將請(qǐng)求主機(jī)的IP地址和物理地址加入到ARP緩存中去 。這基于這樣一個(gè)假定：假如請(qǐng)求者向我們發(fā)送一個(gè)數(shù)據(jù)報(bào)，我們也很可能想向它發(fā)回什么 。
我們使用的ping程序有些非凡，原因在于它使用的編程接口（在大多數(shù)Unix實(shí)現(xiàn)中是低級(jí)插口(rawsocket)）通常答應(yīng)向一個(gè)廣播地址發(fā)送數(shù)據(jù)報(bào) 。假如使用不支持廣播的應(yīng)用如TFTP，情況又如何呢？（TFTP將在第15章具體介紹 。）
bsdi%tftp啟動(dòng)客戶(hù)程序
tftp>connect140.252.13.63說(shuō)明服務(wù)器的IP地址
tftp>gettemp.foo試圖從服務(wù)器或獲取一個(gè)文件
tftp:sendto:Permissiondenied
tftp>quit終止客戶(hù)程序
在這個(gè)例子中，程序立即產(chǎn)生了一個(gè)差錯(cuò)，但不向網(wǎng)絡(luò)發(fā)送任何信息 。產(chǎn)生這一切的原因在于，插口提供的應(yīng)用程序接口API只有在進(jìn)程明確打算進(jìn)行廣播時(shí)才答應(yīng)它向廣播地址發(fā)送UDP數(shù)據(jù)報(bào) 。這主要是為了防止用戶(hù)錯(cuò)誤地采用了廣播地址（正如此例）而應(yīng)用程序卻不打算廣播 。
在廣播UDP數(shù)據(jù)報(bào)之前，使用插口中API的應(yīng)用程序必須設(shè)置SO_BROADCAST插口選項(xiàng) 。并非所有系統(tǒng)均強(qiáng)制使用這個(gè)限制 。某些系統(tǒng)中無(wú)需進(jìn)程進(jìn)行這個(gè)說(shuō)明就能廣播UDP數(shù)據(jù)報(bào) 。而某些系統(tǒng)則有更多的限制，需要有超級(jí)用戶(hù)權(quán)限的進(jìn)程才能廣播 。

推薦閱讀