※ 引述《HYL (HYL@UofArizona)》之銘言： : 我這兩天開始看 JXTA 相關的文件，我比較好奇的是 JXTA 提供了 : 一套完善的 API，不知道版主手上的案子是架構在現有的架構上， : 還是為了效率的問題重新建構一套自己的protocol？ 現在不太可能用 JXTA 的。它既沒效率又沒市場佔有率，基本上多數的 Java 技術都是昇陽自己玩著高興用的，只有昇陽一家外加半個 IBM 的 支援，在他們影響力之外的地方，基本上是推不太動的，也就是說，在 中大型企業市場之外，沒有太多 Java 相關技術的發展空間，其他軟體 廠商也沒有必要為他人做嫁衣裳，順勢而為就可以了，要廠商主動配合 開發系統，是想都別想。 當然 JXTA 有著相對清晰的架構，很適合拿來和其他系統對照和學習， 這是無可否認的。 以檔案交換應用為主的 P2P 而言，則 eDonkey/eMule/Overnet 系列， 和 BitTorrent 系列，佔了絕對性的市場優勢，前者更是勝過後者，還 外加 eMule 為 OSS 的優勢。 所以，如果要使用現有的架構，只有選擇 eMule protocol 一途。 然而就商業和技術考量，則獨立的通訊協定是免不了的。一來沒有既存的 系統負擔，規劃設計上較為方便，二來商業價值較大，客戶是不會接受可 外掛其他軟體的開放或半開放協定的。 : 對於 p2p效率問題我了解的還很粗淺，能想到的就是search query : propagation ，像gnutella那樣沒用到 rendezvous peer的結果就 : 是到了一定的始用者數量後，就被自己先壓死了；另一個問提就是 : bootstrap : 不知版主手上有沒有些經典論文探討這些問題，可否賞個連結 :) 現實的效率問題應該有三個： 1. 搜尋的效能 2. 傳播的效能 3. 防火牆和 DSL 問題 至於 rendezvous peer, router peer 和 gateway peer 等等的東西， 主要是網路架構的問題，雖然高度相關但不能等同。 商業軟體可以不考慮 rendezvous peer, 做集中式搜尋就可以了，反正 客戶捨得花這個錢，也覺得花這個錢比較安心，否則他一定覺得很虛， 就像是給中大型企業做系統，一定要讓他花大錢買主機用 Java, 原本 只要十萬元的系統膨脹為三百萬以上，浪費九成以上的資源，資訊部門 可以開開心心去上教育訓練課程、聽上幾場講座，才會覺得這樣子好。 所以怎樣做比較不會壓垮自己，並且讓每一個搜尋要求的等待時間降到 最低，是我現在主要的問題之一，花錢買主機不是我需要考慮的事。 傳播的問題比較有趣，我覺得 eMule 會成功不是沒有道理的，它加強了 系統的黏性，讓每個人連線時間延長，以促成整體的效能和傳播率。 但 BT 的方式卻是下載效率比較高的做法。 目前我考慮用較為平衡的做法，不要太極端。 防火牆和 DSL 是比較現實的問題，太多人用 DSL, 太多地方有防火牆， 要促進效能，就一定要處理這個問題。 至於相關連結，我是覺得學界都談到別的地方去了，從一開始就是搭 著流行名詞，骨子裡談的還是分散式運算和網路研究，後來網格運算 流行，又都轉向到那裡，繼續談著一樣的東西。 O'Reilly 搞了一個 openp2p.com 可是也沒講到什麼東西： http://www.openp2p.com 我覺得，現實上 p2p 的應用還很狹隘，所以要解決的問題，也是比較 細微的調整、更彈性的規劃，而不是架構性和計算性的設計，到了那個 層次，就已經不是我們所熟知的 p2p 應用了。 而比較經典的東西，我想沒有什麼好說的，就是 IBM SNA 的 APPN (Advanced Peer-to-Peer Network), 也是 p2p 這個名詞的始作俑者。 關於 APPN 可以參考這裡： http://www.networking.ibm.com/app/aiwhome.htm --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 61.222.173.26