查看完整版本: [-- [长文] P2P、ED和BT,不可不知的事 --]

『漫游』酷论坛 -> 精華中的精華 -> [长文] P2P、ED和BT,不可不知的事 [打印本页] 登录 -> 注册 -> 回复主题 -> 发表主题

切斯特·杨 2003-10-10 17:32

[长文] P2P、ED和BT,不可不知的事

P2P 这个词应该都听过吧,对,peer to peer,点对点,那什么样的软件才能算是P2P,过去现在和未来的点对点又如何呢?听我慢慢说来。

通常人们说到点对点,想到的就是一个可以大家自由的交换文件的网络,一堆叫得出名字和叫不出名字的工具,还有在这个网络上丰富多彩的内容,但实际上,从定义来说,P2P并不代表这里的任何一点。如果我说通常认为的与点对点相对的FTP下载实际上也是点对点,你会相信么。事实上,它就是点对点。

从网络传输的方式来看,点对点只代表一种传输模式,相对的是广播和组播等传输模式。要讨论点对点首先要对这个‘点’确定一个范围,在网络拓扑结构中,存在很多很多各种各样的设备,如果我们把‘点’的范围定义为网络主机的话,只要是以单个网络主机开始到其他单个网络主机的数据传输都可以称为是点对点,这和具体实现的软件、协议和方式都无关,所以说,FTP下载实际上也是点对点,因为所产生的网络传输是从FTP服务器这一个点到你自己的计算机这另一个点。由此类推,绝大部分的网络应用都是点对点的,认为P2P就一定好的人该仔细想想了,你所认为的差异实际上并非如你所想。

那么修改一下‘点’的范围是不是能把通常意义上的P2P软件划分出来呢?这确实是可以做到的,但看到最后你会觉得很没意义,太多的限制会降低可比性。能满足很强限制的结果就已经具有了我们所希望的特点,那还怎么去和不能满足限制的结果比较呢?假如我们说这个‘点’指的只是客户机,不算服务器,那看起来确实把FTP下载给分出去了,变成了P2P的对立面,但实际上,这里还存在另外的一个问题,就是什么是服务器,什么又是客户机。

配置很高的就是服务器了么?放在机房里面而不是自己的桌子上的就是服务器?这些都是因果颠倒的说法。所谓的Server,只是一个市场定位的划分,一台放在商店橱窗里面的贴着Server标签的机器实际上什么都不是。如果真的要做一个划分的话,也不能放在计算机上来区别,只能按运行在计算机上的程序来区分,有提供服务的程序,比如Web服务,电邮服务,FTP服务,也有使用这些服务的程序,浏览器,FTP客户段,Outlook等等,大部分时候为了简化概念,我们直接用计算机上运行的服务来称呼计算机,比如Web服务器、电邮服务器、FTP服务器,但实际上,这可能都是在说同一台计算机。那能说运行这些服务程序的计算机就是服务器么?也不能,一台计算机上可以运行的程序多了,只要有一个服务程序就是服务器的话,那差不多所有人的计算机都可以叫服务器,可以看看自己的系统服务列表,里面有没有一个叫Server的东西,那就是一个服务。还是说要定一个百分比,运行的程序中有超过30%的程序的就可以认为是服务器?这就有点点搞笑了。这样来定义‘点’还不能把P2P网络区分出来。

通过定义‘点’来区分P2P实际上是做不到的,因为P2P本身的定义就是与角色无关的一种传输模式,所以需要从别的角度来判断什么是真正通常意义上的P2P。

有一种错误的,但是比较接近正确的划分方法,认为P2P就是没有服务器,实际上,目前除了overnet之外,还没有哪一个公开的P2P软件不需要服务器支持,Overnet在概念上也是把原本集中独立的服务器散布到每一个使用者当中而已。QQ有服务器,MSN有服务器,ED有服务器,BT也有服务器,只是不需要使用者自己去设定或者关心这个服务器,所以说这种划分方法是错误的,那为什么说比较正确呢?因为只要加上一个限定词,就可以在绝大多数情况下适用了,就是‘没有直接提供传输内容的服务器’。在P2P的世界里,服务器所起的作用和FTP,Web等等不同的,这个不同表现在功能上,也表现在数据内容上。P2P的服务器通常只是一个电话簿或者查号台的作用,可以帮助你找到同一个P2P网络中其它的用户,但是,你从P2P网络中下载一个电影文件,这个文件并不存在于服务器上。而如果是FTP的话,你下载的电影那就是保存在FTP服务器上的。

好,现在我们可以区分出什么才是通常所说的P2P了,能够满足这个条件的软件非常的多,别的我们都先放放,只看大家关心的ED和BT。

ED和BT都已经是可以算是第二代的P2P软件了,他们的父辈的功能更加简单,工作方式类似打电话,首先通过查号台,你可以知道住在这个城里的其他人的电话号码是多少,然后打电话过去与对方接通之后,你们俩就能说话,当然别人都听不见,不然也不是P2P了。这个时候,通话的质量,是不是听得清楚,就完全是你们俩之间的事情,如果电话不好或者线路有问题的话,就会经常说:喂喂,我听不清,你大点儿声。如果确实是硬件问题的话,干着急都没有用。这是第一代的P2P。

第二代的P2P则完全不同,是一个非常大的进步。前面写过,P2P代表着两个端,对同一份数据的单向传输来说,FTP这种方式,是传出数据那端可以同时支持多个网络传输。第一代的P2P则很明显是两人世界,数据的传出端和传入端都只能同时处理一个网络传输,只有你知我知,有没有天知地知就不管了。很明显的,还有第三种情况,就是数据接收端可以同时从多个网络传输中接收,这就是第二代P2P的核心内容。

从得到数据的人的角度来看,这样的改变是很有效的。就好像某天Party结束,要送朋友们回家,需要10辆Taxi,打电话给一家出租车公司,公司回复:我们这儿只有5辆空车,那怎么办,先送一半的朋友回去然后再开回来接另一半?我想你肯定会拨打第二家公司的电话。比较一下,这样节约了一半的时间。第二代P2P也是如此。就单个传输内容来说,可以从多个来源同时获得,单位时间内的效率提高,结果就很显然了。

这还只是理论上的方法,要把理论变成现实,变成可以运行在我们每个人计算机上的软件,还是有很多路要走的。而且,现在的下载速度已经不完全是原先的二人世界决定的了,会受到其他因素的影响。

从实现难度上来看,要比第一代的P2P复杂很多,主要体现在服务端上,原来简简单单的一本电话簿一个查号台已经不能满足要求了,现在除了提供别人的电话号码之外,还要把他们家里有多少电视机,多少电冰箱,多少黄油,多少MG34都得一五一十的告诉你,这样你才能知道该去找哪些人,去要你想要的东西。服务端应答的速度快不快,信息收集的是不是完整,是不是最新的信息,这些都会影响到你查询的结果,简单的说,假如当时你只知道这一家出租车公司的电话,那就只能等第二波了,知道的越多,找齐10辆车就会越方便。这些需要的信息都是P2P网络的服务端提供的。

只能查到一个源和能查到10个源所产生的下载速度在通常情况下肯定就已经相差很多。更何况,查到的信息是不是有效,如果明明知道很多出租车公司的电话号码,结果到需要用的时候打电话过去一问都已经倒闭关门或者换了新号码,那也只有傻眼了。可以说,服务端设计的好坏对P2P网络的使用效果产生的影响要大了很多。

假如有两个网络,查询的效率一样,都能返回10个源的话,接下来的事情就和服务端没关系,说到底这还是P2P,真正的数据并不是从服务端来的,对接收数据的人来说,好像同时接通了10路电话与10个人聊天,但聊得是不是愉快还是得看双方的线路情况。发展了这么久的P2P传输实现,已经很难有比较明显的改变,更何况由于有前面说的服务端的差异存在,因为直接通话的双方间的线路差异造成的影响都可以忽略掉。只是在源数量较小的情况下,这个影响才会比较明显,如果源只有一个,那就和第一代的P2P没区别了。

针对这个问题,第二代P2P从一开始就把扩大源的数量作为很重要的功能来做,很自然的,他们想到了让正在下载的人也成为源的做法,尽管这个时候那人还没有完成整个文件的下载,但已经同样可以作为源为别人提供数据。ED也好,BT也好,都是这样。

在P2P网络中,一份数据从一个点发出就等于在另一个点被接受,所以我们会有“总上传=总下载”这样的数据守恒定律。不管是FTP还是任何一种通常意义的P2P,无不要满足这个定律。相对的,多播组播这些传输模式,因为一份数据发出可以产生多份数据的接收,所以定律不适用。通过这个定律,我们也可以理解,为什么在同样的一个P2P网络里面,有的文件下载很快,有的就不行,那正是这个文件所对应的总流量造成的限制。假如你现在需要的不是10辆Taxi,而是100辆,而城里全部的三家出租车公司分别只有20辆,30辆和40辆,那就算全部都给你还是不能满足需要,有些朋友只要等第二波了,更不要说同时还有别人在预约和使用这些出租车,也许第二波都不够呢。源的数量越少,这个差异造成的影响会越明显。

此外,还有一些因素也会对网络效率产生影响的,比如算法的设计,数据块的组织,是一定要出租车公司一次提供至少三辆车,少了不要呢,还是有一辆算一辆,统统要过来呢。这里就有很多的取舍和折中。

噢,我们看到了这么多影响第二代P2P网络效率的因素,那么我们需要对这每一项进行详细的评测才能来说哪一个网络更好用么?不,不需要,我们并不用从非常技术化的角度来做评判,只要看看非技术差异就行了。唯独一点是需要理解的,第二代P2P确实把效率提高了很多,但并不是速度快下载爽的代名词,因为有这么多的制约因素存在,单单从速度上来做比较实际上是不可能的,无法设定一个对各种P2P网络都公平或者说一致的环境,来进行客观和公正的比较。

从非技术原因来看的话,ED和BT也有着非常明显的差别。

ED除了采用的技术不同之外,还是很接近第一代P2P的,无论在开发目的和使用的方式上来看,都很接近,毕竟是第二代的元老,身上还有不少第一代P2P的影子。

每个人都可以把自己的珍藏共享出来,假如有两个人共享了同样的内容,那下载这些内容的人就可以看到两个源,再加上正在下载的人,假如网络里的人很多的话,源的数量还是不少的,每个人共享的内容都不尽相同,所以也有种说法是ED网络中什么都能找到,当然这是夸大了,但对于一个有规模的网络来说,找东西相对来说是比简单的。

这样自由的氛围正是ED产生的目的,一个大家分享人人受益的共享网络,Share成为ED网络的主旋律。不过,ED网络也有不少的问题,有些问题还是从第一代P2P中继承过来的,比如搜索的结果太多,因为每个人可以按自己的喜好分享任何东西,分享了些什么都得记录在服务端,当你在查询的时候如果不是用一个非常准确的查询条件的话,就会像用Google那样,得到一个很庞大却不一定有用的结果。还有,虽然源的数量因为把正在下载的人也统计在内,却没有区分有全档共享和正在下载的源,使得看起来可能有一个不小的源数量的文件实际上却没有一个全档,也就是所谓死档的存在。因为最终的传输是P2P,ED也不能摆脱P2P传输中存在的会阻断这种端对端连接的防火墙,路由器或者内网的影响。也就是困扰很多人的Low ID问题。实际上,正因为ED把这种影响用LowID的方式表现出来,才会被人们注意到,这个问题在任何一种纯粹的P2P软件中都是存在的。这个问题产生的结果是可以看到的源,或者说对LowID的人有效的源的数量比一般人看到的要少些,可以被归入源的数量对网络效率的影响里面,并随着源数量的增加而减弱其影响。可以想象,如果源的数量很多的,就算少了一半也还是很多,而如果源的数量很少,哪怕只少一个也还是很少,所以这并不是会产生严重后果的问题。

ED是这样一种目的和运作方式的软件,由于前面提到的恒等式的存在,为了让某些文件可以更快更好的被下载到,会有各种组织出现,按照组织的约定,对某些特殊的文件提供更多的上传带宽,通过恒等式就可以知道,这意味着下载的带宽也增加了。同样的,下载的人越多,也可以增加源的数量,提供更高的上传总带宽,自然下载也会越来越舒服。这会形成一个良性的循环。ED软件的设计也是为了分享的目的存在的,可以同时Share很多文件,可以设定自己的Nick,让网络中的每个人感觉上都是活生生的,而不是只有一个IP的死计算机。可以设定好友,可以发送Message等等,这些都是当时第一代P2P中非常好非常人性化的设计。而且,正如第一代P2P软件没能取代互联网中爷爷辈的FTP一样,ED也不会取代FTP这样的服务。

再来看看BT,说实话,我是不愿意把这两者放在一起做比较的,因为根本就是存在于两个不同的世界里的,虽然采用了非常相似的技术,都可以称为第二代P2P,但他们的不同是如此之大,使得放在一起比较很大程度是没有意义的。

互联网的发展对商业的促进是非常巨大的,现在人们已经习惯从网络上下载驱动程序啦、系统补丁啦、软件游戏的Demo等等,不过,大部分这样的下载,特别是带有商业行为的下载还是以FTP和Web为主,按前面说的,这也可以算是P2P,那就会有P2P存在的问题,特别是两端间的线路,以及对服务端的负荷。在经济全球化的今天,一家面向全球的企业如何能将自己在网络上提供的这种下载服务做得更好就成为一个关系到企业形象的问题,我自己肯定不会去相信一家连提供的软件补丁下载都会要重试一整天才能下到的公司。但是,并不是所有的公司都有微软那样的实力可以在全球做许许多多的镜像站点,就算这样,前一阵子的蠕虫还是让Windows的升级站点着实苦恼了好几天。要让企业可以用最小的代价满足全球客户的下载要求,这就是BT产生的理由。

无需安装设定,使用简单,这也是与以前任何一个P2P软件不同的,为啥呢?还是因为设计的出发点不同,使用的目的不同。BT并不能如其他P2P那样形成一个分享的社区型网络,没有Nick没有ID什么都没有,无设定的安装,直接点击下载,这些都是为了方便企业的客户使用所做的设计,原先企业提供的下载都是FTP或者直接用Web,那些都是在浏览器里面点击一下另存为甚至可以直接Open来进行操作的,想要用BT来取代原先的Web/FTP方式的话,让用户安装什么复杂的软件,进行复杂的操作都是不可能的,至少不能比原来的操作复杂,这样才会被客户接受。正因为这个目的的差异,所以才会有BT和ED在使用上如此大的不同,并不能说哪一种更好,只能说哪一种更符合软件本身的目标。

这个目标,用简单的话说就是两个字“发布”。BT的全部设计都是围绕发布进行的,简单易用的Web索引界面,无需设定的用户界面,单击下载的使用方式。而且,作为P2P软件中的后辈,对之前的软件中存在的一些不足也做了不少修缮,这些因素综合在一起,让BT一问世就受到很大的关注。但除去光环看本质,BT仍然以第二代P2P为核心传输方式的软件,BT仍然有服务端的存在,BT仍然需要每个下载者提供上传来增加总带宽为其他人服务,这些都是BT与其它同类软件相同的地方。同样也要遵守恒等式定律,BT刚开始的时候不限制上传速度和有些版本对上传限制的特殊化处理都在事实上会更好的利用每个人的带宽。以发布为目的的使用方式,对每个使用的人来说,都不会产生同时很多的下载或上传任务,也有利于集中带宽,种种这些,都是为了保证全网络的总流量,也就是保证所有下载的人可以有很不错的速度。但反过来看,没有什么事情可以两全,带宽集中意味着有效时间短,更高的全网络速度意味着对每个人的带宽占用更高,没有任何的可以区分使用者的设定意味着自主共享精神的淡化等等。

BT的独特表现还在体现在供档的方式上,一开始没有一个很好的可以用来做多个文件供档的软件,虽然在下载者看来,要开一个单独的窗口来做种子不仅会在影响到正常的使用,而且也不能开很多个,在自己的计算机上一大堆种子窗口是没人愿意看到的。但我们从BT产生的目的来看,这点就很容易理解了,作为企业来说,原本就有专用的服务器来提供客户支持,现在只是在这些服务器上运行一个BT来为发布的更新做种子而已,反正服务器也不是平时经常有人去使用的,就算开十几个窗口也没人会抱怨。

至于其他一些经常被提及的BT的好处,我们首先要做一个区分,这个好处是因为BT的独特设计、使用方法还是工作方式而产生的,还是全部的第二代P2P传输方式所产生的,如果是后者,那这样的好处对全部的第二代P2P软件都适用,并不能成为BT比其他软件好的理由。如果是前者,那同样也可以举出其他软件所具有的,相反BT因为设计目的的限制而无法实现的功能来,要想做出孰优孰劣的比较,就好像说螺丝刀和锤子哪个好一样,是不可能简单做到的。P2P软件所需要的,所能做到的,所具有的缺陷和限制,BT不会和其他的软件有什么不同。不同的软件之间的区别并不能成为一个完全取代另一个的理由,只要理性的分析,就可以看到,BT和ED有着多么大的不同,而这些不同并不是产生差别的原因,恰恰相反,使差别产生的结果,这个差别就是“发布”和“分享”。

正如ED从新兴到成熟的过程一样,BT初期的热潮也会慢慢衰退,脱去耀眼的光环,成为世界的一部分。



ps: 假如,仅仅是假如,我们的ED联盟成员改变共享策略,全体都只提供最新的三个发布作品,并且不考虑ED的使用相对BT来说复杂的话,那在“发布”上的效果不会比BT差,这就是第二代P2P传输核心决定的特性。但事实上每位联盟成员都共享了多得多的东西,十几个G是算少的,带宽的分散才会造成发布速度上的差异,但如全面所说的,这个差异可以靠源的数量,也就是下载人的数量来弥补,这也正是漫游始终没有全面的采用BT的原因。这是一个选择,分散还是集中的选择,对于那些需求量很大的,分散之后仍然可以保持一个很高的下载人数的作品,我们用BT,相反地,暂时不用。等到漫游的ED可以接纳BT带来的分散的时候,自然会有更广泛的行动。只是在现在,我们的ED盟成员仍然会尽可能的提供更多的分享,而不是只为了发布,所以,继续支持漫游的ED,尽量使用漫游ED来下载,这是现在对漫游来说最好的帮助和奉献。


ps2: 对于P2P软件伤硬盘这样的说法,不愿发表意见,只想说一句,不要把自己的带宽想的太高了,就这点传输量,硬盘才看不上眼呢。

adslisdn 2003-10-11 00:18
BT是为了满足企业对客户的服务而创造出来的吗?
寒.....
虽然楼主是漫游BT第一人
但是楼主的这个观点实在是让人无法苟同

BT无法长期和大量的SHARE文件
确实是一个问题
但是谁也不能断定BT以后就不能在这方面有所改善
而就目前来说,因为存在着BT"发布"和ED"共享"的区别
所以BT和ED还是一种互补的关系
但是也仅仅是目前而已

woodykin 2003-10-11 01:41
唔唔唔, 个人觉得嘛,
EM/ED 和 BT 也有共享的成份,
BT可以比较集中火力(尽用上传量)发布少量文件,
但BT没有搜索功能这方面, 长期来说要使文件流通很困难呢...

FTP, BT 和 ED 也可以作分享之用途,
但长远成效最重要还是看使用者有没有足够能力(如果我在自己的机器上建立ftp server的话, 我的ADSL可以帮到多少人呢?...>_<), 和使用者有没有长期分享文件的精神.
暂时看来, ED/EM 在功能上最能鼓励用户长期分享吧.

P.S. 个人也很喜欢ED/EM可以设定自己Nick Name和加入好友的功能~

shadowclover 2003-10-11 06:59
引用
最初由 adslisdn 发布
BT是为了满足企业对客户的服务而创造出来的吗?
寒.....
虽然楼主是漫游BT第一人
但是楼主的这个观点实在是让人无法苟同

BT无法长期和大量的SHARE文件
确实是一个问题
但是谁也不能断定BT以后就不能在这方面有所改善
而就目前来说,因为存在着BT"发布"和ED"共享"的区别
所以BT和ED还是一种互补的关系
但是也仅仅是目前而已


BT的官方网站上对BT的介绍就是推荐用它来提供企业面向客户的软件发布。BT的作者也要生活(在号召使用BT的人捐钱),其设计不可避免的会照顾到最可能的使用者,就算一开始没有想那么多,但是它目前的发展方向是软件发布,如自由软件和免费下载的驱动或补丁等,其焦点在于利用下载者空闲的上载带宽提高整个下载带宽,从而更快的更有效的发布,其对手是ftp而不是ed。目前可以说BT还远未成熟,无法达到商用的目的,但对于单个热门文件的发布,已经体现出了它相对于FTP的优势。可以把BT和ED的功能做到一起,就像把剪刀和小刀合成一把多用刀一样(如shareaza),但各自的功能仍然是彼此独立的,没有谁比谁好最后淘汰对方这一说,只有在什么用途上谁比谁合适。

如果出现一种融合bt和ed功能的新p2p程序,那么在用户基数相同的前提下,它的性能应该会类似于ed而不是单个文件时的bt,其根本原因就是chester说的带宽,发布者的带宽基本是满负荷的,积极参与者越多,增加的带宽就多,但这些带宽会分布到所有共享的文件,除非当发布新档的时候所有人自觉提高新档的共享优先级或干脆取消其他文件的共享。

adslisdn 2003-10-11 10:31
引用
最初由 shadowclover 发布


BT的官方网站上对BT的介绍就是推荐用它来提供企业面向客户的软件发布。BT的作者也要生活(在号召使用BT的人捐钱),其设计不可避免的会照顾到最可能的使用者,就算一开始没有想那么多,但是它目前的发展方向是软件发布,如自由软件和免费下载的驱动或补丁等,其焦点在于利用下载者空闲的上载带宽提高整个下载带宽,从而更快的更有效的发布,其对手是ftp而不是ed。目前可以说BT还远未成熟,无法达到商用的目的,但对于单个热门文件的发布,已经体现出了它相对于FTP的优势。可以把BT和ED的功能做到一起,就像把剪刀和小刀合成一把多用刀一样(如shareaza),但各自的功能仍然是彼此独立的,没有谁比谁好最后淘汰对方这一说,只有在什么用途上谁比谁合适。

如果出现一种融合bt和ed功能的新p2p程序,那么在用户基数相同的前提下,它的性能应该会类似于ed而不是单个文件时的bt,其根本原因就是chester说的带宽,发布者的带宽基本是满负荷的,积极参与者越多,增加的带宽就多,但这些带宽会分布到所有共享的文件,除非当发布新档的时候所有人自觉提高新档的共享优先级或干脆取消其他文件的共享。




寒.....
不知道你是在哪个"官方"网站上看到的
我在原始版本的官方网站上
是有看到作者说
"BitTorrent is great! How can I help?
You can give a donation."
欢迎人们进行捐助.

但是没有看到作者提倡或者推荐"用它来提供企业面向客户的软件发布"
虽然有这样一段话:"You have a great product, many customers, and are delivering your product to hordes of happy customers online. Serving large files creates problems of scaling, flash crowds, and reliability. As you grow, they become more central to your business, but your bandwidth costs go up as well. It's a vicious cycle."
但是我从中也看不出有哪句是说明BT是针对企业的
这段话只是说BT是为了"delivering product"而已
反而更象是为了让那些没有自己的FTP或者WEB服务器的共享软件或者免费软件的作者发布自己的作品而使用BT


至于"在用户基数相同的前提下,它的性能"是否会"类似于ed而不是单个文件时的bt"
这个倒是值得另开帖子来讨论的话题了
而chester说的带宽,我倒不认为上传总带宽会等于下载总带宽
因为还必须考虑数据传输途中的额外开销问题
实际上
上传总带宽是大于下载总带宽的
而如何能够让下载总带宽尽可能接近于上传总带宽
则是P2P网络所要考虑的效率的问题
关于这点
我转贴一下







发表于: 2003-06-26 21:10:24发表主题: Gnutella存在重大缺陷,数据传输效率不够高

--------------------------------------------------------------------------------

芝加哥大学的研究人员对Gnutella进行彻底的研究后发现,它的基础架构不符合互联网最基本的拓扑学原理,他们相信,Gnutella在互联网上的运行效率不够高。

该大学的研究人员Matei Ripeanu说,互联网连接的方式是使数据从纽约通过芝加哥传输到旧金山,Gnutella则没有考虑到互联网基本的拓扑结构,可能使数据绕道东京,再被传输到旧金山。他说,被开发人员称为servents的Gnutella节点,同时负责处理与服务器和客户端相关的任务。这些节点提供客户端界面,用户则可以通过界面来发布查询、浏览结果以及接受其他用户的查询。这些节点同时还管理用来维护网络完整性的后台网络流量。为了成为网络中的一员,一个servent会打开一个或多个TCP,与网络中其他节点连接。

Matei Ripeanu的研究小组设计了特殊的“瓟虫”,作为一个servent加入Gnutella网络,并使用Gnutella本身的协议收集其中的拓扑信息。该“瓟虫”能够发现其所有的“邻居”,不断地完成一张Gnutella网络地图。

Gnutella中的网络节点是其效率低下的主要原因。与使用不正确的钥匙打开锁一样,Gnutella的节点不符合互联网的基础架构。Matei Ripeanu说,Gnutella网络拓扑结构中的节点与互联网的物理网络相距甚远。

一些专家表示,该小组的研究只是量化了研究人员早已知道的一个情况,但Matei Ripeanu说,目前还几乎没有完成的对P2P系统的量化评估,P2P网络的离散性和动态性使得它的数据集中工作很难完成。规模较大以及其分布式的基本结构,是他们选择Gnutella的原因。另外,Gnutella的开放式协议也这他们的研究提供了可能。他说,我们坚信,这一问题不仅仅局限于Gnutella。

他同时指出,Gnutella网络正在不断进行完善。目前,Gnutella网络被组织为一种二层结构,超级节点路由其中大部份数据,一般节点则基本上不负责路由数据。

bosch 2003-10-11 11:23
又见到一个超长帖子。切是学文学的?

关于ed,bt的速度,切分析的很好了,事实。集中带宽分享一个文件,和同时分享几十个,上百个文件,单个文件的速度无法比较了。

我的pc目前在ed上分享了140个文件,23GB,过来拉文件的朋友,速度从1~150KB/s都有。

切斯特·杨 2003-10-11 14:55
to adslisdn:

关于“官网”的问题,你说的没错,现在确实没有明确的写是为了企业做的,但现在的这个并不是他们最早的版本,原先在Introduce那页的图上面有一整段,就是以企业给客户提供产品下载做为案例来介绍的。

这个目的并不重要,而且这也是个会改变的不是么,我想要提出的观点是探讨会产生BT和ED这两种差别很大的实用方式的原因,并不是说这样的目的就是不对的,只是以前有些言论把这样的差别作为BT比ED好的论据,这也是不全面的。

4点半 2003-10-11 15:09
引用
最初由 adslisdn 发布

而chester说的带宽,我倒不认为上传总带宽会等于下载总带宽
因为还必须考虑数据传输途中的额外开销问题
实际上
上传总带宽是大于下载总带宽的
而如何能够让下载总带宽尽可能接近于上传总带宽
则是P2P网络所要考虑的效率的问题


e~ ,偶其实也是懂的不多,只是日常使用中有一些体会。也来掺和几句。
如果从字面理解,按说下载带宽要比上传带宽大这才对吧?在没装Cable之前,偶基本只会下载,极少机会给别人上传过。后来用了EM,上传才成了习惯。也用FTP给网友上传几个G的动画,不过速度最多也就是80多K,EM通常也就是达到100K,再要长时间维持更高的速度就很难了。不过下载是随便就可以单线达到180K的速度哪。回想起刚装Cable的那天,兴奋得下了整晚的软件,把以前用小猫时不敢想的大家伙全拉回来,多线程速度高达800K。
这样看,下载怎么也比上传要大吧?还是我理解的地方错了。

不过大家的看法也是很接近的,两者侧重有不同。最起码在目前,ED/EM在长期共享大量的文件这方面是比较优胜的。偶分享400多个,共70多G文件。就不可能用BT了。而且拥有搜索功能也是EM很重要的一个方便条件。BT针对性强,在发布方面拥有操作简单这个优点。以后会否有什么改变,要再看情况了。

切斯特·杨 2003-10-11 15:36
hoho, 4点半理解错了adslisdn的意思,这是总带宽的比较,不是个人的带宽情况。假如考虑数据传输时候软件添加的数据外内容,比如校验码、定位信息等,从数据量来看,传递1M数据实际上传输了超过1M的内容,也就是adslisdn说的总上传大于总下载,不过,我还是按照比较容易理解的有效数据之比相同来写的,提高有效数据的比率也是一个提高实际传输速度的方法,虽然我没有具体看过实现,但感觉起来这方面BT比ED做的好些,不过,这也说明技术在不断进步,不是么。

我并不想讨论BT或ED哪个更好,既然贴在了这里,肯定看到的绝大部分都是ED支持者,或至少是中立的。只是想从不同于BT和ED经常被人能用来直接比较的那些观点的角度来对这两者作一番评价,也是为了去除有些ED死忠对BT抱有的敌对意识,因为这根本还不是在抢同一块蛋糕的直接对手。

tbcr 2003-10-11 17:08
最近的确看到不少有关P2P软件伤硬盘的说法,不知道来源是哪里,如果不是不负责任的硬盘代理商故意制造的话,的确是匪夷所思的顾虑,大约是跟人类害怕自己不了解的事物的传统吧。

总的来说,我是坚信“软件不可能毁伤硬件”这一信条,逻辑操作指令无论如何也不能对设备造成物理损伤,包括以前的“CIH”病毒造成的也不是不可逆转的损伤:找个单片机摊子,把BIOS拔下来重新刷一下就恢复了。

要说P2P软件使硬盘重复读写同一个区域,导致磨损,简直是难以理解,甚至有些资深的IT工程师也对此深信不疑。简单的类比就可以知道这种说法的荒谬,硬盘上的虚拟内存部分,读写操作频繁的程度是P2P软件的几个数量级,也没见每块硬盘都动不动就几百兆坏道。

atkio 2003-10-11 19:03
引用
最初由 tbcr 发布
最近的确看到不少有关P2P软件伤硬盘的说法,不知道来源是哪里,如果不是不负责任的硬盘代理商故意制造的话,的确是匪夷所思的顾虑,大约是跟人类害怕自己不了解的事物的传统吧。

总的来说,我是坚信“软件不可能毁伤硬件”这一信条,逻辑操作指令无论如何也不能对设备造成物理损伤,包括以前的“CIH”病毒造成的也不是不可逆转的损伤:找个单片机摊子,把BIOS拔下来重新刷一下就恢复了。

要说P2P软件使硬盘重复读写同一个区域,导致磨损,简直是难以理解,甚至有些资深的IT工程师也对此深信不疑。简单的类比就可以知道这种说法的荒谬,硬盘上的虚拟内存部分,读写操作频繁的程度是P2P软件的几个数量级,也没见每块硬盘都动不动就几百兆坏道。


“软件不可能毁伤硬件”----
也不尽然,现在工具可以修改CPU频率和电压,损伤是肯定的。


p2p对硬盘无害,我倒是赞同的。

weismann 2003-10-16 14:15
另外一个声音:

楼主对BT的历史非常了解,但是现在的BT已经发展到了可以共享N多文件的地步(贪婪ABC ---> http://bt.greedland.net/greedbt.php),但是没有查询这个功能,所有的搜索必须到种子发布地带才能找到,而且没有好友,这二点是BT绝对的失败。

泛观互联网路,能让大家参与进去的,接近现实,而又与现实有所差距的东西,最能得到广泛支持。

漫游的ED最大的优势有如楼主所说:地区局限,让所有下载的朋友得到更快的速度,也不会产生数据从美国绕一圈回来的搞笑结果。

社会在进步,技术在进步。总之,我喜欢漫游的ED,如果我有能力,也会参与到漫游的服务器里面去。

weismann 2003-10-16 16:15
BT更适合全球大面积的少文件分享(特别是本区域内共享较少的时候)

而ED相对小区域的多文件共享有他的优势

切斯特·杨 2003-10-16 16:31
确实BT的客户端发展很快,单窗口的工具也不少,从BT++到PTC,现在的mod更多了,ABC我没有用过,现在自己的机器上用的是SimpleBT,专门做发布的机器上还是用shadow版做种子。没有看过这些mod的源码不太好说,基本做法可以想到一些的,不同的做法产生的效率也不一样,比如,改单对象为多对象的时候,是整个对象进行复用还是打破对象边界,对核心和外围部分做不同的处理,这里产生的性能和资源开销的差异就很大了。不过,能把各种功能整合在一起,简化使用肯定是好的。希望bt能变得像ftp那么方便,无论是分享还是下载,如果能把其他p2p网络的优点都加上就更好了。

weismann 2003-10-16 16:38
对于楼主的想法,我也赞同,可是这个世界没有完美的事情,特别是软件和网路
必定有高有低,这个世界也是一样,随着社会的进步,必定对某个方面有更高的要求,对于漫游来说,我认为,ED和BT都是必须的。ED和BT都是P2P中的精英(目前),都有各自的好处。对于漫游的发展来说,发展的同时,片源的共享也需要随着发展,对于国内朋友来说,ED更适合,为何?有共同的语言,更快的速度。而BT,相对漫游来说更适合国外的朋友,为何?因为:国外的许多朋友在共享文件方面来说比国内的许多朋友要无私的多(不是崇洋媚外,是事实)。

adslisdn 2003-10-16 17:51
我觉得BT未来的发展方向:

1,严格速度约束,实行1:1或者2:1的上传下载比率,断绝只下载不上传或者上传极端限制速度的现象(这点从客户端着手开发是可以的)
2,开发聊天功能(或者是群组功能),下载同一个文件的人可以进行聊天(可以使用类似DC++的聊天系统)
3,建立USER HASH功能和SEED回报机制,上次当SEED的人在下次下载时会被优先照顾(这点可以参考EM的积分系统)
4,多服务器系统和无中心服务器系统(这点可以参考OVERNET,毕竟现在的BT对服务器的依赖太严重了)
5,免TORRENT文件共享(每次都要制造一个TORRENT文件来发布太麻烦了,而且每次要作种都要重新打开,应该学习EM那样的URL连接形式和一打开就自动共享的功能)
6,客户端使用C++或者C#开发,减少系统资源占用.
------------暂时就想到上面这些,希望将来能够出现一款客户端能够实现上述的想法.....

shadowclover 2003-10-16 18:12
汗,楼上说的不就是ED/EM吗?

我觉得BT和ED一样,优点和缺点都很明显。开发者们肯定正在考虑如何使功能更全面,效率更高。或者以后的新型p2p工具不叫ed,也不叫bt,但肯定会涵盖现有工具的功能。而我们要考虑的就是怎么取长补短,在合适的时间和地方使用合适的工具。

adslisdn 2003-10-16 19:11
引用
最初由 shadowclover 发布
汗,楼上说的不就是ED/EM吗?

我觉得BT和ED一样,优点和缺点都很明显。开发者们肯定正在考虑如何使功能更全面,效率更高。或者以后的新型p2p工具不叫ed,也不叫bt,但肯定会涵盖现有工具的功能。而我们要考虑的就是怎么取长补短,在合适的时间和地方使用合适的工具。



EDONKEY2000也是参考BT开发了HORDE系统
BT参考ED/EM完善自身也是可以的
但是对于ED/EM的效率低下的排队机制
BT是无论如何也不能使用的


查看完整版本: [-- [长文] P2P、ED和BT,不可不知的事 --] [-- top --]


Powered by phpwind v8.5 Code ©2003-2011 phpwind
Time 0.014684 second(s),query:3 Gzip disabled