【正文】 2023年 2月 1日星期三 3時(shí) 48分 11秒 03:48:111 February 2023 ? 1一個(gè)人即使已登上頂峰，也仍要自強(qiáng)不息。 2023年 2月 1日星期三 上午 3時(shí) 48分 11秒 03:48: ? 1最具挑戰(zhàn)性的挑戰(zhàn)莫過(guò)于提升自我。勝人者有力，自勝者強(qiáng)。 :48:1103:48Feb231Feb23 ? 1越是無(wú)能的人，越喜歡挑剔別人的錯(cuò)兒。 , February 1, 2023 ? 閱讀一切好書(shū)如同和過(guò)去最杰出的人談話(huà)。 2023年 2月 1日星期三 3時(shí) 48分 11秒 03:48:111 February 2023 ? 1空山新雨后，天氣晚來(lái)秋。 。 :48:1103:48:11February 1, 2023 ? 1意志堅(jiān)強(qiáng)的人能把世界放在手中像泥塊一樣任意揉捏。 :48:1103:48Feb231Feb23 ? 1世間成事，不求其絕對(duì)圓滿(mǎn)，留一份不足，可得無(wú)限完美。 , February 1, 2023 ? 很多事情努力了未必有結(jié)果，但是不努力卻什么改變也沒(méi)有。 2023年 2月 1日星期三 3時(shí) 48分 11秒 03:48:111 February 2023 ? 1做前，能夠環(huán)視四周；做時(shí)，你只能或者最好沿著以腳為起點(diǎn)的射線(xiàn)向前。 。 :48:1103:48:11February 1, 2023 ? 1他鄉(xiāng)生白發(fā)，舊國(guó)見(jiàn)青山。 :48:1103:48Feb231Feb23 ? 1故人江海別，幾度隔山川。 , February 1, 2023 ? 雨中黃葉樹(shù)，燈下白頭人。就是 MMS協(xié)議結(jié)合 TCP協(xié)議進(jìn)行數(shù)據(jù)傳送。 ? 如果通過(guò) MMSU連接客戶(hù)端，就是 MMS協(xié)議結(jié)合 UDP協(xié)議進(jìn)行數(shù)據(jù)發(fā)送。 ? 同一發(fā)送者的不同接收者請(qǐng)求的固定過(guò)濾類(lèi)型資源預(yù)訂必須合并為共享所給節(jié)點(diǎn)的單個(gè)資源預(yù)訂。 ? 獨(dú)占資源預(yù)訂請(qǐng)求是數(shù)據(jù)包從特殊發(fā)送者處創(chuàng)建的。代表性軟件主要有 Infrasearch、Pointera。這方面的軟件主要有Farsite、 Ocean、 Store等。 二、 P2P技術(shù)應(yīng)用 ? P2P數(shù)據(jù)存儲(chǔ) ? 數(shù)據(jù)存儲(chǔ)類(lèi)軟件用于在網(wǎng)絡(luò)上將文件分散化存放，而不像現(xiàn)在存放于專(zhuān)用服務(wù)器。本質(zhì)而言，協(xié)同計(jì)算就是網(wǎng)絡(luò)上 CPU資源的共享。信令流根據(jù)自己的協(xié)議體系集中完成尋址 /定位、呼叫建立、呼叫拆除等工作， RT語(yǔ)音流直接在主叫與被叫之間流動(dòng)。由于系統(tǒng)資源消耗不多，采用普通的電腦就可以建立直播系統(tǒng)。其次需要 P2P的服務(wù)端軟件來(lái)控制和轉(zhuǎn)發(fā)媒體流。目前在網(wǎng)絡(luò)電臺(tái)、網(wǎng)絡(luò)電視方面有很多應(yīng)用，常見(jiàn)的有 PPLive、 MySee等網(wǎng)絡(luò)電視軟件。 二、 P2P技術(shù)應(yīng)用 ? 即時(shí)通信 ? 允許兩個(gè)或多個(gè)用戶(hù)進(jìn)行快速、直接的交流，易于同非終端計(jì)算機(jī)終端設(shè)備進(jìn)行通信 ? icq、 oicq、 MSN Messenger 、 yahoo messenger 等 二、 P2P技術(shù)應(yīng)用 ? P2P網(wǎng)絡(luò)游戲 ? 網(wǎng)絡(luò)游戲采用 P2P技術(shù)建立起分布小組服務(wù)模型，配以動(dòng)態(tài)分配的技術(shù)，每個(gè)服務(wù)器的承載人數(shù)將在數(shù)量級(jí)上超過(guò)傳統(tǒng)的服務(wù)器模式，這將大大提高目前多人在線(xiàn)交互游戲的性能；同時(shí)每個(gè)游戲用戶(hù)成為一個(gè)對(duì)等節(jié)點(diǎn)，各個(gè)節(jié)點(diǎn)可以進(jìn)行大量的點(diǎn)對(duì)點(diǎn)通訊，從而減少服務(wù)器的通訊任務(wù)，提高性能。 ? 采用集群進(jìn)行下載的對(duì)等網(wǎng)絡(luò)應(yīng)用方式 。它在分布式模式基礎(chǔ)上，將用戶(hù)節(jié)點(diǎn)按能力進(jìn)行分類(lèi)，使某些節(jié)點(diǎn)（超級(jí)節(jié)點(diǎn)）擔(dān)任特殊的任務(wù)。每個(gè)對(duì)等機(jī)在功能上都是相似的，并沒(méi)有專(zhuān)門(mén)的服務(wù)器，而對(duì)等機(jī)必須依靠它們所在的分布網(wǎng)絡(luò)來(lái)查找文件和定位其它對(duì)等機(jī)。 一、 P2P技術(shù)介紹 ? （ 2）分布式 P2P網(wǎng)絡(luò) ? Napster因?yàn)橹醒敕?wù)器的存在引起的版權(quán)糾紛導(dǎo)致了它的破產(chǎn)，以 Gnutella和 eDonkey為代表的后來(lái)者們吸取了 Napster的失敗教訓(xùn)，將 Napster的理念更推進(jìn)一步。這也是 P2P最主要的優(yōu)點(diǎn)； ?●節(jié)點(diǎn)越多網(wǎng)絡(luò)越穩(wěn)定，不存在瓶頸問(wèn)題； ?●信息在對(duì)等節(jié)點(diǎn)間直接交換，高速及時(shí)，降低中轉(zhuǎn)成本； ?●基于內(nèi)容的尋址方式處于一個(gè)更高的語(yǔ)義層。 ?（ 3）區(qū)別傳統(tǒng)的 C/S模式 ，表現(xiàn)形式為應(yīng)用層上基于 P2P網(wǎng)絡(luò)協(xié)議的各種客戶(hù)端軟件。 ?（ 1）各個(gè)節(jié)點(diǎn)對(duì)等，責(zé)任和義務(wù)相同 。 ? （ 3） 2023年用于共享 MP3音樂(lè)的 Napster軟件與美國(guó)唱片界的一場(chǎng)官司 。 補(bǔ)充： P2P基礎(chǔ)技術(shù) ? 一、 P2P技術(shù)介紹 ? 二、 P2P技術(shù)應(yīng)用 一、 P2P技術(shù)介紹 ? P2P技術(shù)起源 ? （ 1） 20世紀(jì) 70年代中期，源于局域網(wǎng)的文件共享 。單播是服務(wù)器和客戶(hù)端一對(duì)一的傳輸方式；多播是一對(duì)多的傳輸方式。廣播就是多人觀(guān)看同一個(gè)媒體內(nèi)容，而且看到的內(nèi)容都是一樣的，用戶(hù)無(wú)法控制媒體播放過(guò)程，只能選擇看或者不看。 如何理解？ ? 點(diǎn)播和廣播應(yīng)該放在一起理解。 ? 網(wǎng)絡(luò)允許服務(wù)器提供數(shù)據(jù)的帶寬有限，客戶(hù)端的最大帶寬＝服務(wù)總帶寬。 ? 由于服務(wù)器不用向每個(gè)客戶(hù)機(jī)單獨(dú)發(fā)送數(shù)據(jù)，所以服務(wù)器流量負(fù)載極低。 ? 現(xiàn)行網(wǎng)絡(luò)雖然都支持組播傳輸，但在客戶(hù)認(rèn)證、 QoS等方面還需要完善，這些缺點(diǎn)在理論上都有成熟的解決方案，只是需要逐步推廣應(yīng)用到現(xiàn)存網(wǎng)絡(luò)當(dāng)中。 ? 由于組播協(xié)議是根據(jù)接收者的需要對(duì)數(shù)據(jù)流進(jìn)行復(fù)制轉(zhuǎn)發(fā)，所以服務(wù)器的服務(wù)總帶寬不受客戶(hù)接入端帶寬的限制。 ? 這種方式由于每個(gè)客戶(hù)端各自連接服務(wù)器，服務(wù)器需要給每個(gè)用戶(hù)建立連接，對(duì)服務(wù)器資源和網(wǎng)絡(luò)帶寬的需求都比較大。 ? 現(xiàn)有的網(wǎng)絡(luò)帶寬是金字塔結(jié)構(gòu)，城際省際主干帶寬僅相當(dāng)于其所有用戶(hù)帶寬之和的 5％。 ? 服務(wù)器針對(duì)每個(gè)客戶(hù)不同的請(qǐng)求發(fā)送不同的數(shù)據(jù)，容易實(shí)現(xiàn)個(gè)性化服務(wù)。 ? 若從獨(dú)立的 Windows Media Player連接到發(fā)布點(diǎn)，必須指定單播內(nèi)容的 URL；若有實(shí)時(shí)內(nèi)容要通過(guò)廣播單播發(fā)布，則該 URL由服務(wù)器和發(fā)布點(diǎn)別名組成。 ? 使用 協(xié)議翻轉(zhuǎn) 以獲得最佳連接。 MMSP ? Microsoft Media Server Protocol ? 在 Inter上實(shí)現(xiàn) Windows Media Server中流媒體文件的傳送與播放。因?yàn)?RSVP的預(yù)定必須建立在完全流方式的基礎(chǔ)上，其可擴(kuò)展性問(wèn)題倍受關(guān)注。接收者實(shí)現(xiàn)預(yù)定后，基于接收者的模式能夠?qū)崿F(xiàn)一種分布式解決方案。發(fā)送一個(gè)流前，發(fā)送者傳輸一個(gè)路 徑信息到目的接收方，這個(gè)信息包括源 IP地址、目的 IP地址和一個(gè)流規(guī)格。 ? RSVP協(xié)議的兩個(gè)重要概念是流與預(yù)定。 ? 與 ICMP和 IGMP相比，它是一個(gè)控制協(xié)議。預(yù)訂請(qǐng)求信息轉(zhuǎn)發(fā)給下一個(gè)上游支持RSVP的路由器。 ? 隧道技術(shù)要求 RSVP和非 RSVP路由器用本地路由表轉(zhuǎn)發(fā)到目的地址的路徑信息。一個(gè)中等規(guī)模不支持 RSVP的網(wǎng)絡(luò)不能執(zhí)行資源預(yù)訂，因而服務(wù)保證也就不能實(shí)現(xiàn)。實(shí)際上， RSVP決不可能在每個(gè)地方都被配置。如進(jìn)入允許控制在某結(jié)點(diǎn)處失敗， RSVP程序給產(chǎn)生此請(qǐng)求的應(yīng)用返回一個(gè)錯(cuò)誤指示。 ? 在每個(gè)結(jié)點(diǎn)處， RSVP程序應(yīng)用一個(gè)稱(chēng)為 進(jìn)入允許控制的本地決定程序 決定是否能提供所請(qǐng)求的QoS。 RSVP RSVP操作模型 ——基本 RSVP協(xié)議 操作 ? QoS請(qǐng)求一般發(fā)源于接收者主機(jī)應(yīng)用，而被傳遞到本地 RSVP應(yīng)用。如數(shù)據(jù)鏈路層媒介有自身的 QoS管理能力，包調(diào)度器負(fù)責(zé)協(xié)調(diào)數(shù)據(jù)鏈路層，獲得 RSVP所請(qǐng)求的QoS。 ? 每個(gè)能加入資源預(yù)訂的路由器將收到的數(shù)據(jù)包傳遞給包分類(lèi)器，然后將它們?cè)诎{(diào)度器中排隊(duì)。 RSVP（ Cont’