<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title>P2p on Shell&#39;s Home</title>
		<link>//blog.shell909090.org/tags/p2p/</link>
		<description>Recent content in P2p on Shell&#39;s Home</description>
		<generator>Hugo</generator>
		<language>en-us</language>
		
		
		
			<copyright>CC-BY-SA4.0</copyright>
		
		
			<lastBuildDate>Fri, 15 Jun 2007 01:56:38 +0800</lastBuildDate>
		
			<atom:link href="//blog.shell909090.org/tags/p2p/index.xml" rel="self" type="application/rss+xml" />
			<item>
				<title>论P2P构架的变革</title>
				<link>//blog.shell909090.org/blog/archives/393/</link>
				<pubDate>Fri, 15 Jun 2007 01:56:38 +0800</pubDate>
				<guid>//blog.shell909090.org/blog/archives/393/</guid>
				<description>&lt;p&gt;目前P2P正在蓬勃发展，不过其中也有很多问题。本文试图列举目前P2P所碰到的最大几个问题，并分析成因和解决方法，最后提出一种P2P传输方式。&lt;/p&gt;&#xA;&lt;p&gt;P2P传输目前所碰到的几大问题有，传输数据不可控，及其衍生出的版权控制问题，广告控制问题，病毒控制问题。传输速度和传输持续性的冲突。“吸血”、“限速”和“卡种”。搜索的敏感性和代价。传输过程的保密和安全性。&lt;/p&gt;&#xA;&lt;p&gt;首先讨论最大的一类问题，传输数据不可控，又称为无障碍特性。所谓传输数据不可控，是指所有通过P2P共享传输的数据都无法被某个人标记和阻止。Http的网页内容很容易被封锁掉，而ED/BT的数据可就封不住了。基于这个特点，很多人都用P2P来下载XXX内容。不过相对来说有利有弊，这同样造成了病毒，色情，暴力的泛滥。而且衍生了另外一个相当巨大的问题，版权问题。&lt;/p&gt;&#xA;&lt;p&gt;上文可知，单个个体是无法对P2P内容的传输构成干扰的，此处的个体不单单指个人，还包括了企业实体等等。相对的全体则是指所有个体的集合。其实从某种意义上说，上面一句根本就是说，P2P传输内容不受干扰。那么我们可以想见，如果是一般传媒，个人利益受到侵害的时候个人是无力的，企业利益收到侵害的时候企业是财大气粗的。但是P2P这里，企业和个人一样无力了。因此P2P就成了很多企业的眼中钉肉中刺，而保护版权，就是他们最好的理由。其实从某种意义上来说，传统媒体就没有版权的问题吗？P2P传播方式就一定带来版权问题吗？&lt;/p&gt;&#xA;&lt;p&gt;而更进一步来说，我们面对着自由传播和反自由传播的斗争。前者认为人类的知识财富应当为人类所共有，前人的知识应当能让后人学习。而后者则认为人类的知识应当保密，以便能带给创造知识的人利益。前者为黑客时代的精神核心，目前的开源软件基金即继承了此种思想。其中哪种更好确实难说，没有学习就没有进步，可是没有利益谁去学习呢？&lt;/p&gt;&#xA;&lt;p&gt;OK，言归正传，当前我们面对着版权保护上的困难。从根本上说，我们应当考虑的是如何才能在新情况下重新分配利益，而不是如何阻拦技术的进步以保护旧有的利益格局。尽力争取将其价值内在体现而不是外在化，更直接的说就是尽力使得公开技术本身就能获得收益，而不是拿去卖钱。例如将内容公开，而且从感兴趣的人中收集潜在客户，或者是在内容中引导宣传等等。此时P2P的无障碍特性不但不是缺陷，反而是优势。&lt;/p&gt;&#xA;&lt;p&gt;而后，P2P的传输速度和传输持续性的矛盾。其实严格来说这并不是矛盾，P2P越热，传输速度就越快。但是一个东西的热度总是有限的，因此就P2P应当牺牲持续提供下载的能力来保持传输速度，还是牺牲传输速度来保证持续下载的能力。P2P分成了两类，ED阵营和BT阵营。本质上说没有什么问题，要保证又有持续下载性又有速度是很困难的。因此这个问题是一个内在的矛盾。&lt;/p&gt;&#xA;&lt;p&gt;再而后，“吸血”、“限速”和“卡种”的问题，这也是P2P最为内在和难以解决的一个问题。所谓吸血，是ED术语。指仅仅从别人那里下载，而不为别人提供上传的人。在BT中就是减小上传，下了就跑。限速是P2P术语，指限制上传和下载速度。卡种则是BT术语。指当上传到99.9%的时候停止发布，使得大量的人维持在99.9%无法完成下载的方法。实践证明短期的卡种可以“强迫”下了就跑的人持续“做种”上传，使得整体速度提升。但是时间长一点就会打击某些下载积极分子的积极性，导致跑种，浪费带宽。在ED中，使用收益上传者来解决此类问题。&lt;/p&gt;&#xA;&lt;p&gt;本质上，这个问题是源于P2P的核心思想的。P2P认为，我为人人，人人为我。但是有人的带宽要收费，有人懒得为别人做贡献，怎么办？于是吸血骡等等软件和方法就应运而生。下载的时候凶猛，上传的时候不给。于是整体的速度就被吸血骡拖慢了，所有人的下载也越来越困难。为了对应吸血骡和下了就跑的人，人们开发了收益上传者系统和卡种方法，不过都是治标不治本。技术无论如何进步，都解决不了人自身的贪婪。&lt;/p&gt;&#xA;&lt;p&gt;至于限速，则是一个两说的话题，有人认为限速拖慢了整体网速，有人认为限速无妨。其实应当这么说，如果一个人限速的时候同时限制了上传和下载速度，那么无所谓。如果上传限速一点点，下载限速非常高，或者根本不限速。那么只能说RPWT了。&lt;/p&gt;&#xA;&lt;p&gt;搜索的敏感性和代价，这个问题不是一个完整的P2P上的问题。可以说，这个问题牵涉了互联网的本质，即信息的收集和获得。作为P2P来说，在信息的敏感性和代价上具有特殊的特点。&lt;/p&gt;&#xA;&lt;p&gt;最简单情况下，数据被集中到核心服务器上，搜索者驱动核心服务器来做搜索。当数据量增大后，核心服务器就无法支撑了。于是这时候出现了集群服务器，即以一组服务器替代一个服务器。按照读写发生的频率，又可以分为多对等服务器和多分离服务器两大类型。多对等服务器将每个服务器视为具备相同的数据，查询操作可以在和单服务器同等的时间内完成，但是更新和修改操作就必须花费原来时间的N倍，同时数据存储成本是单服务器的N倍。而多分离服务器则认为每个服务器负担一部分数据，更新和修改操作的时间比单服务器略长，模糊查询操作则需要付出原先N倍的代价，数据存储成本则和单服务器一致。前者可以看做是RAID0的变形，后者则是RAID1的变形。当前主流产品都具有多负载冗余的能力，基本就是RAID5的变形。&lt;/p&gt;&#xA;&lt;p&gt;在更复杂的情况下，例如互联网的数据索引，当前的服务器根本无法支撑。于是就产生一个基础想法，分布式数据库。分布式数据库又可以称为网格数据库。和分布式数据库本质的区别在于，无协调状况下可以自适应的分布数据，并且完成数据的冗余工作。简单来说，理想状态下一个机器加入或者离开网格的影响只体现在性能上。&lt;/p&gt;&#xA;&lt;p&gt;听上去很好，不过实际还有很多问题。例如ED中使用的Kadimila协议就是一种分布数据库系统，具体请看前面的一篇文章。Kadimila的最大弱点在于无法模糊搜索。通俗的说，一般搜索引擎，“国家体制”搜索的出的东西，“国家”的搜索结果中一定也有。虽然不一定靠前，能让你一次看到。然而，Kadimila协议中，“国家体制”搜索的出的东西，“国家”基本就出不来了。这是因为需要通过关键字来计算HashNum，然后查找索引了数据的计算机。关键字变了，索引也变了，因此结果就不一样了。&lt;/p&gt;&#xA;&lt;p&gt;这是一个关键而难解决的问题，问题的关键则在于“必须根据关键字做出索引”上。如果没有关键字索引和根据索引查找机器，那么查询就会在所有机器上实行。从而带来非常大的开销。而通过关键字索引的话，目前没有一种算法能够获得一个上下文所有的关键字。因此我们只能将内容和可能最大的几个关键字关联，最终导致搜索不全。&lt;/p&gt;&#xA;&lt;p&gt;最后就是传输过程的保密性和安全性，这是一个密码学上的双重意义的概念。保密就是传输的内容不会为第三者所知道，安全性则是传输的内容不会为第三者篡改。当然，在这里还要加入一个不会为第三者阻拦。&lt;/p&gt;&#xA;&lt;p&gt;P2P的客户端大部分数据都来自其他客户端，由此，其他客户端可以巧妙的构&lt;/p&gt;&#xA;&lt;p&gt;造传输内容，使得客户&lt;/p&gt;</description>
			</item>
			<item>
				<title>P2P和DHT的结构</title>
				<link>//blog.shell909090.org/blog/archives/336/</link>
				<pubDate>Fri, 15 Dec 2006 19:29:29 +0800</pubDate>
				<guid>//blog.shell909090.org/blog/archives/336/</guid>
				<description>&lt;p&gt;最近P2P是越来越盛行，按照公司要求，我们要写一个P2P下载支持。老板发话，越小越好。想想有道理，只是要减轻服务器压力，又不是要和P2P下载商抢生意。不过老板又发话，必须保持核心服务器高可用性。偶当场啥掉，怎么办？&lt;/p&gt;&#xA;&lt;p&gt;说起P2P下载的原始面目，其实是很简单的技术。假定你一个人在下载一个文件，同时你又知道所有有这个文件或者在下这个文件(那就有一部分)的人的套接字。那么连接上去下载，并且提供你可以提供的部分就好了。其中只有两个问题(也和算法没啥关系)，应该先下谁的，应该先给谁。但是困难在于，你如何知道谁有某个文件呢？&lt;/p&gt;&#xA;&lt;p&gt;按照获得这个信息的方法不同，P2P分成三代。&lt;/p&gt;&#xA;&lt;p&gt;第一代是核心服务器型的，术语叫做中心化拓扑（Centralized Topology）[1]，例如Napster[4]。这种类型的P2P下载可以说是传统下载和P2P下载的结合体。他同时具备了P2P的特性，例如带宽占用分布，高容错，高可用。也具备了核心模式的特性，例如中心依赖，可模糊搜索。Napster可以说就是因为核心依赖性而输掉了官司。&lt;/p&gt;&#xA;&lt;p&gt;这代P2P的运作方式是，用户上线的时候把自身的资源提交到服务器。由服务器维护表来做查询，并且定时删除过期的客户。用户查找文件的时候需要向服务器提交请求，服务器返回拥有文件的客户端。由于文件信息提交到服务器端，因此服务器上可以说是拥有版权文件的索引。&lt;/p&gt;&#xA;&lt;p&gt;第二代是泛洪/限制性泛洪型的，术语叫做全分布式非结构化拓扑（Decentralized Unstructured Topology）[1]，代表就是Gnutella[3]。这种类型的P2P才是完全意义上的P2P，因为去掉了核心服务器，因此没有中心依赖性。拥有P2P良好的带宽占用分布，高容错，高可用性能。但是致命缺点是，当网络节点扩展时，维护网络的带宽消耗就会成几何扩展。在大规模应用中，这无疑是不可接受的。所以有限制性泛洪的结构，不过限制性泛洪只是增强网络的抗性，没有根本的改变现状。&lt;/p&gt;&#xA;&lt;p&gt;这类P2P的运作方式是，用户维护自身拥有文件的列表，和其他一些客户的列表。当一个用户需要知道谁有一个文件的时候，就向他所有知道的其他客户查询。如此反复层级查询，并且用SPT或者TTL来做优化，最后可以得到结果。不过可想而知，网络消耗是惊人的。&lt;/p&gt;&#xA;&lt;p&gt;这代P2P有个变形，术语叫做半分布式拓扑（Partially Decentralized Topology）[1]，代表是KaZaa。简单来说就是把核心服务器型的一个核心服务拆成多个分布在某些比较强大的节点上。核心服务间使用泛洪/限制性泛洪型的方式通讯，核心和非核心间还是核心服务器查询的老路子。这类P2P修正了核心服务器型的中心依赖问题，并且可模糊搜索。也修正了泛洪的带宽占用问题。但是资源消耗分布不均匀，结构比较复杂，而且长期运行的核心节点可能莫名其妙就成为了被告，因为核心节点也拥有版权文件的索引。&lt;/p&gt;&#xA;&lt;p&gt;第三代是DHT型，术语叫做全分布式结构化拓扑（Decentralized Structured Topology）[1]，代表就是Chord[6]，Pastry[5]，Kadamila[2]。这种的P2P也是去核心的，拥有P2P良好的带宽占用分布，高容错，高可用性能。同时资源消耗比较平均，网络消耗小，扩展性好，抗网络不稳定能力强。缺点就是失去了模糊搜索的能力，只能变通的模糊搜索。&lt;/p&gt;&#xA;&lt;p&gt;DHT是Distributed Hash Table的缩写，用于节点搜索的。在此之前，我们先来想想数据结构课程的一些东西(没学的就表看了，看下面的吧，这节看了铁晕)。如果我需要知道一个对象，找出关联的一个对象，那应该用哪种结构？map！那如果要增加map的效率怎么办？hash table！那么hash table的内存布型怎么处理？如果要经常删除添加，那应该用链表。OK，我们想像一下，假设一个节点就持有链表中的一项，上下项的指针改成上下节点的网络描述，那是啥？Bingo，DHT。当然，DHT不会傻到让一个节点就保存两个网络描述，那一旦断裂就全玩完。DHT中是先给予所有节点一个ID，然后定义一个距离算法，再按照ID来保存hash的。一个节点保存和他的ID相邻的一定距离的hash(当然还包括值)，并且保存一些ID近的节点的网络描述和一些节点远的网络描述。就好像在hash table里面，一个节点保存了上下临节点的同时，也保存了很远的节点的指针。这样在链表查询的时候速度可以更快。&lt;/p&gt;&#xA;&lt;p&gt;DHT的运作原理是，一个节点加入DHT网络，就会生成一个不重复的ID。然后会寻找一些节点来扩充自己的相邻节点列表，并且获取于自己相邻到一定程度的Hash的内容。当节点够多的时候，所有的Hash都会有一个以上的节点来维护，这样就有了足够的容错性，性能，稳定性。在寻取一个内容的时候，会寻找自己的临节点列表中最近的节点，然后向他查询进一步的消息。这个在几次循环后就可以足够近到获得目标信息了。当然，大家可以看出，要寻取一个对象，就必须有这个对象的hash，因此是不可模糊的。&lt;/p&gt;&#xA;&lt;p&gt;Kadamila是eMule所用的服务，很多BT中也使用了兼容协议。&lt;/p&gt;&#xA;&lt;p&gt;另外顺便在此提出一个P2P流的思想。传统的P2P下载是基于块的，简单来说就是文件。现在很多P2P技术可以基于流，就是可以在允许一定延时的情况下，将延时允许区域内的数据作为一个块来传送。这种技术对于P2P的要求更高，但是应用范围更加广阔。例如用于视频流播放，广播，股票数据传输等等。现在的流技术都是针对特定协议来展开的，例如视频流点播就用PPstream。我们可以将P2P流封装成一个独立服务，从发起端上连接一个接口，到客户端上监听一个接口，中间过程透明化。简单来说，发送端上运行一个服务，客户端上运行一个服务。发送端上的服务连接到一个特定端口来获得数据，然后通过P2P流来传输给客户端，客户端的P2P服务再监听到一个端口上，向所有(或者有限)连接上的接口提供数据。除去只能接受数据，并且存在一定延迟和丢包外。整个过程就被掩盖在了单纯的网络传输下面。这样很多协议可以在不修改协议(但是至少要可以对抗错包丢包等等网络状况)的情况下直接P2P流化。当然，P2P流在实时性，安全性上的要求会更加高。&lt;/p&gt;&#xA;&lt;p&gt;顺便说一下网状模型的一个修改吧，几年前的东西了，可惜一直弄不出算法来。当前的网状模型是一个节点传输给其他节点，然后层级传递。理论上应该将发起节点最近的和提供带宽最高的节点放在顶层，以减少网的层数。不过将底层的节点带宽废弃还是可惜了点。我们可以将一个流分成两个部分(如果先天就可以分离最好，例如视频和音频，不过他们不对等)，然后组成两颗树。这样网络中的底层节点就可以在另外一颗树中被定义为次层节点。如此会对带宽利用更加彻底，当然，程序也会更加复杂。&lt;/p&gt;&#xA;&lt;p&gt;参考和引用:&lt;/p&gt;&#xA;&lt;p&gt;1.P2P网络的拓扑结构:&lt;a href=&#34;http://www.intsci.ac.cn/users/luojw/P2P/ch02.html&#34;&gt;http://www.intsci.ac.cn/users/luojw/P2P/ch02.html&lt;/a&gt;&lt;/p&gt;&#xA;&lt;p&gt;2.Kademlia协议:&lt;a href=&#34;http://www.itslife.net/blog/?p=132&#34;&gt;http://www.itslife.net/blog/?p=132&lt;/a&gt;&lt;/p&gt;&#xA;&lt;p&gt;:&lt;a href=&#34;http://blog.csdn.net/colinchan/archive/2006/05/08/712760.aspx&#34;&gt;http://blog.csdn.net/colinchan/archive/2006/05/08/712760.aspx&lt;/a&gt;&lt;/p&gt;&#xA;&lt;p&gt;3.Gnutella协议:&lt;a href=&#34;http://www9.limewire.com/developer/gnutella_protocol_0.4.pdf&#34;&gt;http://www9.limewire.com/developer/gnutella_protocol_0.4.pdf&lt;/a&gt;&lt;/p&gt;&#xA;&lt;p&gt;4.Napster官方网站:&lt;a href=&#34;http://www.napster.com/&#34;&gt;http://www.napster.com/&lt;/a&gt;&lt;/p&gt;&#xA;&lt;p&gt;5.Pastry 工程:&lt;a href=&#34;http://research.microsoft.com/~antr/PAST/pastry.pdf&#34;&gt;http://research.microsoft.com/~antr/PAST/pastry.pdf&lt;/a&gt;&lt;/p&gt;&#xA;&lt;p&gt;6.Chord 工程:&lt;a href=&#34;http://pdos.csail.mit.edu/chord/&#34;&gt;http://pdos.csail.mit.edu/chord/&lt;/a&gt;&lt;/p&gt;&#xA;&lt;p&gt;7.对等网络中主流分布式哈希算法比较分析:&lt;a href=&#34;http://www.p2psky.com/tech/article1274.html&#34;&gt;http://www.p2psky.com/tech/article1274.html&lt;/a&gt;&lt;/p&gt;&#xA;&lt;p&gt;8.细说 Kademlia:&lt;a href=&#34;http://www.vshj.com/Article/2005/200512/Article_18386.shtml&#34;&gt;http://www.vshj.com/Article/2005/200512/Article_18386.shtml&lt;/a&gt;&lt;/p&gt;</description>
			</item>
			<item>
				<title>分布式软件构架的变革</title>
				<link>//blog.shell909090.org/blog/archives/289/</link>
				<pubDate>Wed, 22 Feb 2006 03:34:53 +0800</pubDate>
				<guid>//blog.shell909090.org/blog/archives/289/</guid>
				<description>&lt;p&gt;分布式软件构架由来已久，从最初的并行计算到现在的大规模网络并行计算，再发展到网格计算。这代表了分布软件的一个变革，而另外一个变革则是从数据-程序-界面合一的构架转换到数据-程序-界面分离的构架。MVC大家都很熟悉吧。现在软件界的三大困扰是什么？安全，效率，可复用。其中程序从界面层剥离开造成了当前你用出bug的程序可以对别人施加影响，而程序和数据层间的紧密结合更加剧了这个问题。还有程序到界面的接口是最影响成本和收益的地方，因为界面和程序的可复用是最能降低成本的。&lt;/p&gt;&#xA;&lt;p&gt;我们现在流行的一种模式是使用网页界面的B/S模式，诚然，这种模式比C/S模式有更大的优点。客户端与系统无关，这样客户端的可复用性非常好。但是这种模式的缺点也是明显的。网络传输效率低（这个现在没有多少人计较了），构架不合理（人家HTTP本来是传输文件的说），而且不安全。&lt;/p&gt;&#xA;&lt;p&gt;我们相信将来的软件设计模式是基于分布的，那么可能如何分布呢？我个人认为有两种主要模式，一种是平台抽象式分布，一种是组件抽象式分布。&lt;/p&gt;&#xA;&lt;p&gt;平台抽象式分布是指软件的运行在一个网络平台上，其具体运行在哪个电脑上，如何协调对象，并不是软件关心的内容。平台负责抽象了机器，平衡了性能，增加了效率，但是对于机器间的传输实时性要求比较高。适用于企业内部的发展方向，以多台电脑平衡性能。均衡性能需求峰值，降低硬件成本，并且可以充分利用旧机器。用于这种分布的基础是分布式操作系统，在系统运行后即无条件陷入分布系统的接管中。前台的模拟为纯终端，后台模拟为纯资源。然后终端向资源登陆。这种模式的近似产品是win2k中的AD，不过AD只提供了资源的访问指向和访问控制，还有权限分散管理模型。而没有提供最核心的内存共享和锁定，还有线程分布和游离运行。&lt;/p&gt;&#xA;&lt;p&gt;组件抽象式的分布其核心是将一个软件分离到不同的组件中，不同的组件在不同的机器上运行。这种模型更适合于自由的广域环境，当然前提是能成功解决组件通讯的问题。现在这种模型相对前种有更广的发展。这种模型和现在的B/S模式中最大的差异是，B/S模式的用户接口是浏览器和服务器程序共同完成的。从来没有人听说过有页面直接驱动后台组件的吧。如果我们可以用一种抽离语言（JAVA的显示效率太低了）来完成前台的接口部分模块，那么我们应该试图用这种方式来发布软件的前台端。这样软件的抽象更为简单明确，而且可复用性更高。&lt;/p&gt;</description>
			</item>
			<item>
				<title>Bittorrent</title>
				<link>//blog.shell909090.org/blog/archives/169/</link>
				<pubDate>Tue, 31 May 2005 21:34:32 +0800</pubDate>
				<guid>//blog.shell909090.org/blog/archives/169/</guid>
				<description>&lt;p&gt;关于纯粹的BT技术，并没有啥好说的。BT的迅猛发展表明了这个技术的生命力。不过BT还要面对几个问题。首先，也是最大的一个，就是Copyright的问题。&lt;/p&gt;&#xA;&lt;p&gt;嗯，先回顾下网络文件发布的方式和版权追究的历史。最开始的互联网是bbs形式的，而且比firebird一类的telnet形式还要落后。这种情况下要么是通过bbs交换文件，要么就是ftp。多数是大学在用，很少有追究版权的，而且多数东西用于研究时可以藐视版权法。所以这个时期根本没有所谓版权的问题。&lt;/p&gt;&#xA;&lt;p&gt;然后就是欧洲某个研究所（似乎是欧洲核物理研究所）搞出的html协议，到今天成为了xml协议的基础。这个协议可以在客户端灵活的使用各种媒体对象表示，而不用管对方是啥系统。今天的xml可以保存和创建各种内存对象也不用管是啥系统，从某个意义上说，这是一脉相承的重大进步……呃，好像扯远了。这个时候出现的各种文档基本都是本人发布或者转载，多数也是大学使用，没有版权问题。&lt;/p&gt;&#xA;&lt;p&gt;后来我们的网络渐渐转向民用，这个时候微软也搅合了进来，发布了IE。然后很多网站就搞了个人主页服务。还有部分小型网站根本就是大流量的个人主页。为了吸引访问量，经常东抄抄西搬搬。这个时候就有了盗版的概念，不过盗版的多数是文字，也经过修改。这个时期的后期渐渐演变成了盗版歌曲，Mp3格式之争由此而来，相信大家非常熟悉了。&lt;/p&gt;&#xA;&lt;p&gt;网页毕竟比较好处理，盗版的人虽然多，不过稍成气候就可以一个警告让ISP关闭服务。唱片公司们虽然头痛还比较好处理。（当然，他们可能认为这已经是比较严重的问题了。但是和后来的境况相比，他们的却还没有见到啥大场面。）而后出现了分布式的歌曲共享系统和搜索引擎，这让各个公司大大的头痛了。两者的结合使得免费的歌曲在网络上满天飞，整个唱片行业据说损失惨重。唱片公司们为此甚至将歌曲共享先锋的Netisper（貌似这个名字，偶忘记了）告倒了。不过倒了一个人，起来千万个。反正目前来说，唱片公司已经放弃封杀所有免费歌曲流行的可能。改成授权下载了。用非常低廉的价格销售所谓“授权正版Copy”。老实说对于这个我非常的佩服，不但宣传了自己，减少了盗版损失。对于我们来说，合理合法，支持了自己喜欢的歌手，而且还方便查找。这手算是诸公司们非常成功的举措。&lt;/p&gt;&#xA;&lt;p&gt;然后就是近代，Edonkey和Bittorrent为代表的两种DFS横空出世（其实ED是个老家伙了）。满世界乱飞的盗版根本没法解决，而且盗版的范畴从主要是音乐和文字扩展到了各个领域。从游戏到电影，啥都有。甚至严重的打击了盗版商，将中国多年未竟的反盗版销售的事业推向了顶点。一个卖盗版的朋友是这么评价的：“以后我们只卖三种软件光盘，系统，office，大众软件”。我今年的所有电视和电影都是从网络上下载的。由此可见我们的盗版正式进入了战国时代。&lt;/p&gt;&#xA;&lt;p&gt;为盗版而生想必不是P2P软件的本意，不过去除盗版后P2P恐怕没啥明天可言。不信你可以上bt.btchina.net数数到底多少共享是有授权的，包括shareware，XXX授课录像Live这种就算授权过好了。照样是盗版比非盗版多。但是P2P极大的刺激了网络的发展，并且可能成为将来的一个核心技术。&lt;/p&gt;&#xA;&lt;p&gt;当然我相信，立个法禁止P2P软件简单。但是，这是倒退，而不是进步。P2P软件现在逐渐分布化，BT可以自我组件平台，并且透网络运行，凡可上网处皆可BT。如此优良的技术弃而不用，岂非倒行逆施？但是相对，BT也无法参照歌曲运营的模式来个网络授权正版。如此一来，BT被告上法庭的机会就非常高。要是真的禁止了BT，相信会有新的共享软件应需求而生，状况非但没有好转，反而恶化。绝对不是立法禁了就解决的了的。&lt;/p&gt;&#xA;&lt;p&gt;目前来说，寻求一种共享中盈利的模式是当务之急。不但是各个损失惨重的公司，而且是众多的BTFans。如果公司倒了，我们还能BT啥呢？&lt;/p&gt;&#xA;&lt;p&gt;另外一个就是BT的共享方式。BT的算法仅仅可以用于静态文件，这点另我非常不齿。目前最需要分布运行的多数都是动态数据，例如电视广播，股票数据等等。BT不可以用于动态数据的原因我比较清楚，因为我曾经就算法设计问过运筹的老师。不过有分流比没有分流好，仔细看看当今诸多股票提供上捉襟见肘的状况就可以知道了。如果BT2.0协议提供包括动态数据流和认证下载，网络穿越在内的一系列能力，相信会非常具备竞争力的。这个我早在一年前就考虑过，不过奇怪的是，我预计一年可以实现，现在都快一年半了……根本没有声音。&lt;/p&gt;</description>
			</item>
	</channel>
</rss>
