※ 引述《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