有关P2P技术问题

Posted 2023-04-15

现在一些视频软件都用什么P2P技术，到底这个P2P技术是怎么样一个原理啊，请各位给讲一下？

1 P2P技术原理

什么是对等网络(P2P)技术？P2P技术属于覆盖层网络(Overlay Network)的范畴，是相对于客户机/服务器(C/S)模式来说的一种网络信息交换方式。在C/S模式中，数据的分发采用专门的服务器，多个客户端都从此服务器获取数据。这种模式的优点是：数据的一致性容易控制，系统也容易管理。但是此种模式的缺点是：因为服务器的个数只有一个(即便有多个也非常有限)，系统容易出现单一失效点；单一服务器面对众多的客户端，由于CPU能力、内存大小、网络带宽的限制，可同时服务的客户端非常有限，可扩展性差。P2P技术正是为了解决这些问题而提出来的一种对等网络结构。在P2P网络中，每个节点既可以从其他节点得到服务，也可以向其他节点提供服务。这样，庞大的终端资源被利用起来，一举解决了C/S模式中的两个弊端。

P2P网络有3种比较流行的组织结构，被应用在不同的P2P应用中。

(1)DHT结构

分布式哈希表(DHT)[1]是一种功能强大的工具，它的提出引起了学术界一股研究DHT的热潮。虽然DHT具有各种各样的实现方式，但是具有共同的特征，即都是一个环行拓扑结构，在这个结构里每个节点具有一个唯一的节点标识(ID)，节点ID是一个128位的哈希值。每个节点都在路由表里保存了其他前驱、后继节点的ID。如图1(a)所示。通过这些路由信息，可以方便地找到其他节点。这种结构多用于文件共享和作为底层结构用于流媒体传输[2]。

(2)树形结构

P2P网络树形结构如图1(b)所示。在这种结构中，所有的节点都被组织在一棵树中，树根只有子节点，树叶只有父节点，其他节点既有子节点也有父节点。信息的流向沿着树枝流动。最初的树形结构多用于P2P流媒体直播[3-4]。

(3)网状结构

网状结构如图1(c)所示，又叫无结构。顾名思义，这种结构中，所有的节点无规则地连在一起，没有稳定的关系，没有父子关系。网状结构[5]为P2P提供了最大的容忍性、动态适应性，在流媒体直播和点播应用中取得了极大的成功。当网络变得很大时，常常会引入超级节点的概念，超级节点可以和任何一种以上结构结合起来组成新的结构，如KaZaA[6]。

2 P2P技术应用现状

由于能够极大缓解传统架构中服务器端的压力过大、单一失效点等问题，又能充分利用终端的丰富资源，所以P2P技术被广泛应用于计算机网络的各个应用领域，如分布式科学计算、文件共享、流媒体直播与点播、语音通信及在线游戏支撑平台等方面。

(1)分布式科学计算

我们知道，许多计算机的CPU资源并不是时刻保持峰值运转的，甚至很多时候计算机处于“空闲”状态，比如使用者暂时离开等情况。而P2P技术可以使得众多终端的CPU资源联合起来，服务于一个共同的计算。这种计算一般是计算量巨大、数据极多、耗时很长的科学计算。在每次计算过程中，任务(包括逻辑与数据等)被划分成多个片，被分配到参与科学计算的P2P节点机器上。在不影响原有计算机使用的前提下，人们利用分散的CPU资源完成计算任务，并将结果返回给一个或多个服务器，将众多结果进行整合，以得到最终结果。

世界最著名的P2P分布式科学计算系统非“SETI@home”项目莫属。SETI@home项目(简称为S@H或SETI)，由美国加利福尼亚大学伯克利分校在1999年发起，是至今最成功的分布式计算项目。SETI@home通过分析从射电望远镜传来的数据来搜寻地外文明，这在不少科幻迷甚至是很多普通大众眼里都是一个“很酷”的应用。SETI的早期版本截至2005年已经吸引了543万用户，分析了大量积压数据。正如宇宙的浩瀚一般，需要计算的数据(即存在宇宙空间的无数无线电信号)也是海量的。可以说，这几百万台终端组成了一个目前最快的高性能计算机都望尘莫及的“超级计算机”。

(2)文件共享

要问一百个网友目前中国最流行的文件下载方式，恐怕99个都会回答是“BT”。“BT”是BitTorrent[7]的简称，是一种依赖P2P方式将文件在大量互联网用户之间进行共享与传输的协议，对应的客户端软件有BitTorrent、BitComet和BitSpirit等。由于其实现简单、使用方便，在中国用户之间被广泛使用。BitTorrent中的节点在共享一个文件时，首先将文件分片并将文件和分片信息保存在一个流(Torrent)类型文件中，这种节点被形象地称作“种子”节点。其他用户在下载该文件时根据Torrent文件的信息，将文件的部分分片下载下来，然后在其他下载该文件的节点之间共享自己已经下载的分片，互通有无，从而实现文件的快速分发。由于每个节点在下载文件的同时也在为其他用户上传该文件的分片，所以整体来看，不会随着用户数的增加而降低下载速度，反而下载的人越多，速度越快。

BitTorrent是一种无结构的网络协议。除了BitTorrent之外，还有不少著名的无结构化的P2P文件共享协议，典型的有Gnutella[8]和KaZaA[6]。

Gnutella协议是一种最典型的完全分布式、无等级结构的P2P网络模型。网络中的节点随机连接若干个其他节点，称之为“邻居”。这种结构能够很好地适应P2P网络中节点频繁加入与离开的动态特性，因为任意一个节点都可以被新加入的节点作为“邻居”而连接，任意一个“邻居”也可以随意地离开网络。同时，这种加入节点和离开节点的选择是节点间的独立行为，随机分布于网络之中。所以说Gnutella的网络具有健壮性、实时性、可靠性、负载平衡等优势。

在Gnutella网络中存在以下问题：

冗余消息多，对带宽的消耗存在一定的浪费。Gnutella网络协议采用泛洪式(Flooding)消息传播机制，这种消息传播机制产生了呈指数级增长的冗余消息。据统计，P2P软件白天占Internet上运行带宽的40%～70%，晚上有时能达到80%。
搜索效率低，可扩展性差。Gnutella网络的搜索协议将所有资源与节点统一对待，没有考虑节点的性能差异，也没有利用查询成功的历史经验，使得搜索效率低下。

KaZaA协议中节点大体上也是无结构连接的。但是在KaZaA协议中存在一种“超级节点”。这种“超级节点”其实是来源于各个普通的客户端节点，但它们一般具有计算能力强、接入带宽大、在线时间稳定等特点。在KaZaA协议中，超级节点承担着部分服务器的任务，如管理部分普通节点，负责搜索消息的转发等。每一个节点上线后会寻找一个超级节点挂靠，并和原先挂靠在该超级节点下的其他普通节点随机相连，组成一个小的无结构网络。普通节点的共享文件索引汇报给所挂靠的超级节点。因而，KaZaA网络大体上可以看作是两层的无结构网络，上层是超级节点组成的无结构网络；下层是普通节点组成的多个无结构网络，按所挂靠的超级节点分成多个簇。当普通节点发起文件搜索请求时，将请求消息发给所挂靠的超级节点，超级节点从自己存储的共享文件索引信息中查找区域内符合条件的文件，同时将搜索请求转发给若干个其他超级节点，由它们返回其区域内搜索结果。如果需要，这个转发过程可以执行多步以获得更大范围内的搜索结果。这样的混合式结构对异构的终端节点“分而治之”，可以充分利用一些能力较强的终端节点来担任“小”服务器的角色，可谓是“人尽其才，物尽其用”。

除了这些无结构的P2P文件共享协议之外，几乎所有的DHT网络都可以并已经用来实现文件共享的应用，如Chord、Pastry、KAD、CAN等应用。

(3)流媒体直播

曾经人们以为P2P做文件共享最合适，但现在大家发现P2P模式是如此适合于流媒体直播，以至于研究热点在很短的时间内迅速转移到P2P的流媒体上来。中国最早的P2P流媒体直播软件应该算香港科技大学计算机系研究的Coolstreaming[5]、华中科技大学集群与网格计算湖北省实验室研究的AnySee[9]以及清华大学的Gridmedia等系统。

Coolstreaming是一款基于网状无结构网络拓扑的流媒体直播软件，中文名叫做“酷流”。在Coolstreaming中，每个节点通过登录服务器(BS)进入网络，并得到一些邻居列表。每个节点和邻居之间共享媒体数据。Coolstreaming中节点共享媒体数据是基于一种称作“数据驱动”的机制。首先，对于节点缓冲区内所拥有的数据，使用一种“缓冲映射表”(Buffer Map)来进行标记：对于每一秒的媒体内容，如果节点已经从节目源或邻居处获取，则标记该秒数据为“1”，否则标记为“0”。这样，一个80秒长度的缓冲区就对应一个80位长度的缓冲映射表。其次，节点之间以“心跳”(Heartbeat)方式定期交换各自的缓冲映射表，通过比对得到自己没有而邻居拥有的数据位，然后根据数据调度算法，选择合适的邻居，请求得到相应的数据。Coolstreaming采取全网状结构组织网络中的节点，每个节点连接20个左右的邻居，在定期交换缓冲映射表的同时，还要交换自己的邻居列表。这样，在一个邻居离开时，可以从它最近提供的邻居列表中选择一个连接数没有达到上限的邻居作为“替补”邻居进行连接。最早期的Coolstreaming是采取随机选取邻居的策略，即从BS上随机返回一些当前在线的节点列表，然后随机从中选择一些节点进行连接，在选择“替补”邻居时也是随机的。这样做同时又可以达到一定程度的负载平衡效果，因为每个节点连接的邻居数基本是均匀的。但是这样做的缺点也是明显的，两个距离很远、连接很差的节点也可能被调度成为邻居，大大影响的系统的服务质量。

华中科技大学集群与网格计算湖北省重点实验室是中国最早研究P2P流媒体直播的小组之一，它所研发的AnySee软件期望能够使得用户在网上任何时候任何地点都能观看多媒体直播节目。

AnySee的第一个版本基于树状结构：节目源是一个多播树的根节点，之后的节点被调度为其“儿子”或子树。每个节点向其父节点索要数据，并将数据提供给多个子节点。这样的结构可以使得节点快速加入到网络中，并且可以根据IP邻近原则构建起一棵IP多播树，使得节点加入位置都是和自己IP邻近的节点，从而优化服务质量。之后AnySee推出第二个版本，结合了原有的树状结构和流行的网状结构，使得“控制数据走树，媒体数据走网”，既能帮助节点快速定位到加入点，又能实现一定程度的负载均衡，并缓解了原有纯树状结构中底层节点和顶层节点之间播放时差较大的问题。最近的AnySee版本已经取消了树的结构，演化成了优化的网状结构(如图2所示)，即每个节点维护一定数量的邻居成员，并从中选出最合适的“伙伴”节点与之交换数据。伙伴的数量既有上限又有下限，在不满足下限时，节点会不断寻找新的合适节点加入伙伴列表；在达到下限时，节点停止主动寻找伙伴的过程，但可以接受其他节点将其加入伙伴列表的请求；在达到上限时，节点不再和新的节点建立伙伴关系。

除了学术界对P2P流媒体直播的研究外，中国还涌现了很多成功的P2P流媒体直播商业产品，如PPLive、PPStream、沸点和TVAnts等，其中以PPLive最为有名。PPLive目前拥有数百个频道，在2006年“超级女声”决赛期间，频道观看人数达到十万人，可以说是把P2P发挥到了极限。此外，国外也有不少对P2P流媒体直播的研究，如SplitStream[10]等。

(4)流媒体点播

由于观看直播节目时用户不能选择观看指定片段，所以在人们热烈研究P2P流媒体直播时，已有人开始将目光转向P2P流媒体点播服务。目前成功推出P2P流媒体点播的机构还不多，典型的有GridCast[11]系统、PPStream点播系统。GridCast也是一款由华中科技大学集群与网格计算湖北省重点实验室于2005年12月份成功研发并投入使用的对等视频点播系统，具有支持多人共享点播片段、跟踪(Tracker)服务器用户引导、环状结构内容组织等特点。由于一个点播频道的人数往往不会太多，所以在用户进行视频录放(VCR)操作时(即前后拖动播放点、暂停/继续播放等操作)，能否快速将用户定位到观看该点节目的其他用户处就成了P2P点播技术的关键。为了实现快速定位，GridCast中采取了一种同心圆环的媒体内容组织结构。在每一个节目频道里，媒体内容按指数递增的区间进行划分，例如一个一个半小时的电影节目，可划分成[0, 5]、(5, 15]、(15, 35]、(35, 75]和(75, END=90]几段，其单位为分钟。每个节点记录几个正在观看各个段之间内容的节点。这样，在和AnySee类似的网状结构中，可以定期交换这种分段记录，从而，在某个用户拖动观看点时，可以快速定位到相应段的记录节点处，并从这些节点当时所观看的区间内得到大量备用记录以请求该区间媒体数据。此外，GridCast还根据用户习惯对数据调度策略进行优化。

(5)IP层语音通信

IP层语音通信(VoIP)是一种全新的网络电话通信业务，它和传统的PSTN电话业务相比有着扩展性好、部署方便、价格低廉等明显的优点。在全球范围内的VoIP应用中，由于通信各方可能处于不同的网络状况下，所以采取少数几个服务器来进行话音包中转不仅存在压力过大的问题，还可能无法为指定通信双方提供满意的通话质量保证。所以采取P2P技术动态自适应地根据通信双方网络进行链路控制与消息转发是可行的解决方案。

目前风靡全球的Skype[12]即是一款典型的P2P VoIP软件。Skype由于能够提供清晰的语音质量和免费的服务，使用起来又方便快捷，所以吸引了全球数千万的用户，每天在线用户达500万人，并且注册用户数每天增加15万。基本上，Skype采取类似KaZaA的拓扑结构，在网络中选取一些超级节点。在通信双方直连效果不好时，一些合适的超级节点则担当起其中转节点的角色，为通信双方创建中转连接，并转发相应的语音通信包。

(6)网络游戏平台

大型网络在线游戏和网络对战游戏是不少“网虫”的至爱。但由于服务器能力有限，大型网络在线游戏往往需要限制场景人数或者不断增加服务器，而网络对战游戏也必须局限在局域网内进行或者依赖独立的服务器端程序及机器实现Internet上的电子竞技。目前，已有研究人员将P2P技术引入网络游戏和网络游戏支撑平台中。

目前较为成功的P2P游戏平台是华中科技大学集群与网格计算湖北省重点实验室推出的PKTown[13]系统。PKTown系统是一个支持多种网络对战游戏的P2P平台。P2P网络对战游戏平台的难点在于将严格延时约束的节点聚集在一起，这由对战游戏本身要求所决定：延时是影响对战游戏用户体验的关键因素。在众多在线用户中，如何将新加入用户调度到周围都是延时邻近的环境中去呢？PKTown也是采取GridCast中出现过的指数增长的同心圆环方式，很好地解决了这个问题。

PKTown不需要改变游戏本身的代码，而是将用户和Internet邻居组建成一个虚拟局域网，将游戏发出的通信包截获后负载上虚拟局域网的地址，转发出去，游戏进程接收到之后认为是来自同一局域网的游戏包，则可以正常进行游戏。目前PKTown支持魔兽争霸、星际争霸和反恐精英几款游戏，已经在高校范围内进行公测，并成功举办华中科技大学第三届Race War游戏大赛，用户反应良好。

3 结束语

自P2P技术从1999年出现之后，现在已经发展繁荣起来。前文中提到的很多技术都已经趋近成熟，如拓扑构建和内容分发等相关技术。由于P2P架构灵活，适用面广阔，所以将P2P应用到新领域的现象层出不穷，P2P的软件产品也如雨后春笋一般爆炸性增长。

通过本文的描述可以看出，P2P蹬基本原理是容易实现的，人们的研究方向也由基础架构的构建和维护及优化算法等桎梏中摆脱出来，开始深入到P2P技术的根本性问题中去。最新的研究成果表明，不少研究人员已经开始将重心转入到覆盖层网络的节点延时聚集研究、覆盖网之间(Inter-Overlay)优化研究、P2P支撑平台研究以及P2P安全方面的研究等方面。相信随着对P2P技术研究的不断深入，人们能够对P2P计算有一个更深入的认识并解决目前P2P领域中大部分科学问题。可以预见，P2P所带来的技术创新和应用创新还将继续。 参考技术A 好多费话..说白了就是一边下载一边上传...
这样达到提速

有关使用 WCF 服务的 MVVM 模式的一般问题

【中文标题】有关使用 WCF 服务的 MVVM 模式的一般问题

【英文标题】：General questions regarding MVVM pattern with WCF service

【发布时间】：2014-04-13 14:38:05

【问题描述】：

我正在通过 WCF 服务使用 MVVM 模式构建我的第一个 WPF 应用程序。我是这项技术的新手。经过大量工作并在这个社区的帮助下，我设法为我的应用程序创建了基础，从数据和服务层到使用 MVVM 模式和 WPF 的完整客户端。尽管如此，对这项技术仍有一些概念上的担忧/怀疑，也许有人可以帮助澄清一下。

我的问题

1) 只要我不了解每个 view-viewmodel 都不知道 其余视图的退出。这意味着每个视图都有他的 视图模型是孤立的。所以当我需要在我的应用程序中发生什么 显示视图的实例，它创建一个新视图并需要获取 调用者视图上的这个子视图的结果？在这种情况下，每个视图 has 是 viewmodel，所以我如何在它们之间共享这些信息 视图/视图模型？

2) 我的 WCF 服务将 POCO 的对象暴露给客户端。所以这是 本质上是一个脱节的环境。那么报告呢？如果我 遵循 MVVM 指南，我应该联系我的 WCF 服务 viewmodel，获取对象，然后以某种方式公开我的属性 必须绑定到 XAML 中的报表对象，对吗？所以报告应该 不知道我的数据库。我可以使用哪些对象来构建我的数据库 允许我使用 POCO 的对象作为数据源的报告？

3) 我知道的这个在社区里有点争议。我的数据和 服务层使用从 数据库，没问题。现在我的疑问是，当我与客户沟通时， 我应该使用相同的对象还是构建自己的自定义对象？

4)当我需要将标题细节对象保存到数据库时（例如 来自客户的采购订单），我应该创建一个自定义对象吗 具有标头对象的实例和详细信息项的集合 在服务器端，或者这是视图模型的工作？

5) 谁能给我一个实际的例子，说明什么时候每个视图模型有多个视图是有用的？从我一直在做的事情来看，我得出的结论是，每个视图都非常依赖于视图模型，

任何评论将不胜感激。我正在努力遵循良好的编程 在这里练习。

更新

在复活的 cmets 之后，我将尝试澄清我的问题：

关于 1) 我曾怀疑这是 MVVM 的关键问题之一。无论如何，我试图远离外部工具，因为过去我有过严重的问题。当您确实遇到外部工具包的问题时，要找到答案是非常困难的，有时甚至是不可能的。不能使用 Visual Studio 中的基本 MVVM 用一种不太复杂的方法来解决这个问题吗？

关于 2) 我还没有使用任何东西。我在提前考虑。您如何建议以 MVVM 方式构建我的报告？过去，我使用断开连接的 Crystal 报表对象做过类似的事情。我在服务器中进行了查询（使用记录集），使用 XML 或其他方式将数据发送到客户端，然后在客户端将数据再次转换为记录集并将报表数据源设置为此对象。我正在考虑类似的方法，但使用 pocos 类和 MVVM。有什么想法吗？

关于 3) 我认为这就是我一直在做的事情，但我不确定。例如，当我需要用客户填充组合框以过滤客户订单时，我会直接公开我的 POCO 类。我知道这不是更有效的方法，因为当我只需要 2 o 3 个对象时，我需要传输我的对象的所有属性，但为简单起见，我发送了整个对象。当我需要在网格中显示结果过滤客户订单时，我使用一个自定义类，其中只有我想在网格中显示的属性。当您说“我创建 DTO”时，您是说这个吗？ POCO的类不也是DTO吗？

关于 4) 当我需要插入或更新主详细信息对象（而不是客户购买订单）时，通常涉及对至少 2 个或更多数据库对象进行更改。所以我的问题是：我应该在包含单个数据库对象类的数据层中创建和公开一个复杂的对象吗？还是更好地公开基础对象并让viewmodel处理单个对象并将它们一一发送到服务层进行更新？希望清楚。

大约 5) 我怀疑。我会记住的。 谢谢！

【参考方案1】：

这是 WPF 中 MVVM 的固有问题。有两个库可以帮助解决这个问题。看一眼 Caliburn.Micro 使用 ViewModel 优先方法来解决这个问题 问题。另一个库是微软自己的 Prism 库。这 库采用视图优先的方法来解决这个问题。

您如何生成报告？如果您使用的是 s-s-rS 之类的东西，他们有自己的公开 WCF 服务来检索报告。 您可以将其包装在一个服务中并在您的 ViewModel 中使用它。

视情况而定。你的对象有多复杂？如果您正在执行简单的操作，则数据模型可能没问题。然而，对于更多 复杂的操作我倾向于创建一个 DTO（数据传输对象） 包含一个工作单元。

我不确定我是否理解这个问题。

您应该努力让每个视图模型始终拥有一个视图。如果有理由有一个单独的观点，可能有一个很好的理由 有一个单独的视图模型。您可能遇到的问题是 与 #1 相关，并且您希望以某种方式在这些视图之间共享数据。

总体而言，我知道您的痛苦，并且出于您所述的某些原因，我对使用 MVVM 的 WPF 有着爱/恨的关系。在我在 #1 中列出的两个框架中，我使用了 Calibrun.micro，它使 WPF MVVM 更易于访问和使用。一个很好的入门博客文章是：

http://www.mindscapehq.com/blog/index.php/2012/01/12/caliburn-micro-part-1-getting-started/

如果你愿意，你也可以看看棱镜：

http://compositewpf.codeplex.com/

还有一些其他的。这是我经历过的两个。棱镜没问题。但是，我个人不喜欢他们的导航服务。

希望这会有所帮助！

【讨论】：

感谢您的精彩回答！我编辑我的问题以添加更多详细信息。如果可以的话，请看一下。