p2p型blog的优缺点及其原理讨论

一、什么是p2p型的blog?有什么优缺点?
再强调一次,我所理解的“p2p”是"person to person"的意思,也即是抛弃中心点、个人面对个人直接地直接交流的意思。p2p技术几乎可以让网络上现有的一切服务的质量都有质的飞跃。例如传统的http或ftp文件下载服务,完全可以用bt的思路改造,从而达到对服务器的依赖最小、下载性能极大优化的目的。
blog作为web2.0时代的一个标志性服务,它是有“去中心化”的意愿的。很多bloger都自己架起了blog服务器。可是毕竟架设blog服务器需要一定的资金和一定的时间,并不适合与普通网民使用。但是我们如果采用p2p技术,让任何一个网民都可以在本机(甚至是局域网内!)直接写blog,那么该多好啊。
这样的blog系统的优点有:
    1、个人架设blog的成本为零。只要拥有一台可以上网的电脑即可,唯一麻烦的地方是最好24小时开机。甚至不必有公网IP,P2P系统可以设计为跨局域网的,详见后面实现。
    2、blog的容量是无限大的。你在你的本地blog上放一万张图片、一千部电影都没问题,只要你的硬盘足够大。
    3、发表blog变得非常容易。没有上传的问题了,你就是直接在本机上写blog,保存到本机。
    4、速度飞快。因为它使用了类似于BT的分布式下载技术,有“浏览的人越多,速度越快”的特点。详见后面的原理部分。
    5、blog的程序自己可以完全控制。p2p型的blog程序可以在本地机器上有完全的运行权限,不管什么程序都可以跑。这一点对普通的bloger的吸引力不够大,但其实它非常重要。它意味着这个blog的开放性,任何程序员都可以轻而易举地在这个平台上开发blog服务程序。
说了这么p2p型blog的优点,该说说它的缺点了。下面两个简直是p2p系统的致命弱点:
    1、p2p型blog服务与普通浏览器不兼容。访问者只有用专门的软件才能访问。
    2、p2p型blog服务程序难以直接使用现有的blog服务程序。什么.text系统,什么wordexpress系统,统统不能直接使用。rss和atom也要开发专门的插件后才能使用。
这两个难题的解决方法已经超出了技术的范畴,这里就不再讨论了。

二、p2p型blog的思路要点
前几天的一篇文字中已经说过,p2p系统的一个特点就是每个peer的性能都很糟糕,所以p2p系统一定要使用分布式下载的方法,以便提高下载速度。分布式下载还有利于进行NAT穿透:即使双方不能直接收发消息,系统也能从其它人那里取得所需的数据。
那么我们应当怎么应用分布式下载的方法呢?
先考虑传统的方式是怎样的。每个浏览者都是直接从消息发布者那里查询信息和下载文件,这样的系统是很容易实现的。浏览器与blog发布者联系,取得blog目录。用户点击哪个标题就向发布者取哪个网页回来显示。当用户准备发表评论时,直接将评论发送过去。这一切都非常简单。

那好,我们下面来考虑如何将上面的流程改为分布式下载的。

第一步,将blog目录信息打包成一个文件。这个文件可以共享出去,让用户以分布式方法下载。
这个文件的更新是比较频繁的。blog的一切变化都反映在这个文件里了。当用户有新blog发布,或者有新的评论到来,或者blog中涉及的文件作了更改之后,系统都应当自动生成一个blog目录文件,并且将其共享出去。blog目录中包含有每篇blog的hash。这个文件的下载是很频繁的,所以应当尽量设计得紧凑一些。
浏览者想看发布者的blog,他就与发布者联系,取得blog目录的hash及文件大小。然后他就可以用分布式的方法来下载这个文件,一般来说,下载速度会很快。下载到本地之后,解释显示此文件,即可得到该用户的blog目录。

第二步。blog目录中包含有每篇blog的hash。发布者在发布blog的时候,每个blog必须生成一个文件,并且计算出了hash、向p2p网络提交了共享。所以浏览者根据blog目录中所包含的blog hash,也能用分布式的方法下载每篇blog。

第三步。下载blog中引用的图片、音乐等附件。注意,blog文件中引用其它文件(如图片等),不能直接根据URL引用,而是必须提供文件的hash,而且该文件必须是已经在网络中有共享的。

为了充分利用分布式下载的优势,文件划分的越小越好。越小的文件,变化的可能性就越小,能分布式下载的可能性就越大。一张图片可能被很多篇 blog引用。如果图片被集成到了blog文件中,那么浏览者每下载一篇blog就要下载一次那张图片。但如果图片是独立的,那么用户无论浏览多少篇blog,只要下载一次那个图片就足够了。而且,浏览同一篇blog的人不会太多,但是浏览引用了该图片的blog的人却会多很多。
“文件重用”原则与面向对象的“代码重用”的原则是类似的。文件划分得越小越好。面向对象设计中,也提倡将对象尽可能的设计得小一些,一个小功能就一个小对象。小,才好重用。
举个反例。如果我们把整个blog所有的内容都打包成一个文件,那么用户除了要下载很多他不想看的资料之外,他还很难找到同样拥有这个文件的用户。因为信息发布者的blog有只要有一个小小的修改,整个文件的hash就是完全不同了。

第四步。
我们还要考虑blog评论的问题。一般来说,blog的正文是很少变化的。用户写完一篇blog之后就很少会修改它的内容。
但blog发布之后,浏览者会对它进行评论。
要利用分布式下载的优势,我们必须区分出系统中的哪些部分是经常变化的,哪些部分是稳定的。经常变化的部分和稳定的部分不要打包在一起,否则会导致稳定部分也不能分布式下载。这个原理与面向对象设计的原理也是很像的,即:不要把易变的部分和稳定的部分糅合在一起,应当用不同的对象(文件)将它们区分开,以便缩小变化所产生的影响。
所以,blog正文和它的评论不能打包在一起。

结论:
所以,一个p2p的blog系统应当是这样的:
每个用户的blog目录作为一个文件共享出去;
每篇blog的正文打包成一个文件;
blog中引用的其它文件也单独共享;
每篇blog的评论也打包成一个单独的文件共享。

这样的设计之后,用户的信息就组成了一棵树。通过树的根(blog目录的hash),可以找到所有的blog,进而找到blog所引用的图片.
这里有一个规律:任何一个节点的变化,都会导致它的父节点的变化,并且这个变化一直向上传递下去,直到根节点为止.所以这样的一个blog实现,如何维护这样一棵树,是一个重要的问题.否则,很容易形成一大堆的死链接.

这样的设计之后,浏览者必须从信息发布者那里获取的,只有一个hash码(blog目录文件hash)。其余的所有信息,都是利用了分布式下载的机制下载的,保证了下载者的下载速度,也节省了发布者的带宽。
在这种情况下,系统还可以考虑提供一个中转服务器,将对等点之间的连接率提高到100%,那么就不会产生因NAT打孔失败而导致无法连接的情况了。这个中转服务器不会太忙,因为对等点之间必须直接通讯的信息不多。
这种系统还很容易实现权限控制。blog目录hash必须从信息发布者那里获得,所以发布者可以准备多几个目录文件,针对不同的访问者返回不同的目录文件hash。这样就达到了浏览者权限控制的目的。

评论 4
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值