|
要完成有用的工作PP 应用程序中的对等点必须能够彼此发现对方和与对方交互软件开发人员 Todd Sundsted 在本文中继续研究 PP 计算并描述了几种完成这一任务（称为发现（discovery））的方法以及每种方法的优势和弱点 对等应用程序是一种大规模但又是细粒度的应用程序每个对等点都可以进入或退出 — 每个对等点都关注于自己的任务在他们短暂的活动期间尝试完成布置给它们的任务这些任务中的大多数都要涉及与其它对等点交互 管理体系结构（对等点在这种体系结构下运作）必须为构成完整 PP 应用程序的对等点提供许多必要的服务在我们的 PP 计算旅程中已经讲述了通信和安全性服务（请参阅参考资料）现在是时候来研究对等点发现服务了 对等点发现服务使 PP 应用程序中的对等点能够彼此定位以便相互之间可以交互实现对等点发现服务有多种方法我们先从告诉对等点彼此之间的存在这种最简单的方法开始显式点到点配置 显式点到点配置 显式点到点配置与其说是一种真正的发现机制还不如说是一种用来避免实现发现的机制每个存在的对等点都知道居住在其 PP 世界中的其它对等点 术语点到点（pointtopoint）意味着在 PP 应用程序中的每个对等点都知道需要不断与之交互的每个对等点并与之相连这种连线不必将每个对等点都连起来 — 将每个对等点和其他各个对等点彼此相连是不太可能的 — 但是不这样做（无论是有意与否）将会使某些对等点产生网络盲点 我为本系列文章所构建的简单的 PP 应用程序（请参阅参考资料）使用显式点到点配置每个对等点必须预先配置其它所有对等点的地址如果您已经下载并使用了那些代码则您无疑已经经历了忍受这一需求所带来的挫折 — 配置既单调乏味又容易出错更不用提一般的麻烦了 一般而言分布式应用程序中节点的显式点到点配置不能很好地扩展到具有较多节点的大型网络那就是为什么分布式计算应用程序和技术总是（也有一些显着的例外）包含命名和定位功能这也解释了为什么域名系统（DNS） — 一种分布式命名系统最终取代了用于机器命名的主机文件（hosts file）机制维护主机文件是单调乏味容易出错的并且一般来说很难在大型网络环境下运转 但是显式点到点配置并非一无是处点到点寻址缺乏灵活性的特性也带来了一定程度的安全性通过对网络中的每个对等点预先设置它所知道并且将要与之交互的对等点列表使得网络在外部攻击面前表现得很稳固 动态发现模型 与显式点到点配置方法的静态特性截然相反目录服务和网络模型具有动态特性这些模型通常能更好地符合 PP 应用程序它们倾向于该领域中动态的一边 在下面几节中我们将研究三种不同的机制对等点通过这些机制动态地定位其它对等点和了解它自身所属的环境 目录服务模型 在目录服务模型中一台或多台有特殊用途的服务器为对等点提供目录服务为了使可扩展性最大化对应用程序进行了结构化设计以便少量的目录就可以为数量众多的对等点服务对等点向目录服务注册关于自身的信息（其名称地址资源和元数据）并通过根据目录服务器中信息的查询使用目录服务来定位其它对等点 图 说明了一个使用目录来向对等点提供位置和命名服务的 PP 体系结构目录本身可以是对等点（尽管是很庞大的对等点）或者可以只担当目录而不作它用 图 目录服务模型 目录有两种类型这两种类型因为其目录集中式管理的程度不同而有略微的差别 PP 领域中目录模型的最佳示例是 Napster 和与 Napster 几乎一模一样的 OpenNap在 Napster 模型中采用集中式管理目录虽然采用集中式管理的目录遭到本质上是非 PP的指责并且事实上促使了 Napster 被弃用但它确实提供了一个重要的优势集中式管理使它容易确保服务器硬件和配置能足以达到服务质量目标 如果我们先暂时将 PP 放一放可以发现 DNS 是分散式目录的一个优秀示例与因特网本身相似DNS 设计为甚至在部分网络受到严重破坏的情况下仍能工作DNS 目录采用层次化结构根目录代表顶级域（譬如com）它将子域查询服务（如这样的域）的任务委派到下一层次的 DNS 服务器 在任意一种情况下只有目录位置必须配置到每个对等点中这对于点到点模型有重要优势为加入到 PP对等点将自己注册到集中目录服务器回忆上面的图当对等点 A 希望与一个它不知道位置的对等点交互时对等点 A 向目录服务器发送请求然后目录服务器向 A 返回那个对等点的位置 网络模型 图 说明了另一种 PP 应用程序它由许多对等点组成这些对等点在功能上很类似没有专门的目录服务器对等点必须使用它们所在的网络来定位其它对等点 图 网络模型 正如名称所暗示的网络模型 PP 应用程序由一些（通常是动态的）对等点组成没有一个对等点知道整个网络的结构或者组成网络的每个对等点的身份相反对等点只知道直接与它们通信的对等点 — 它们通过代理参与到大型网络中 对等点必须合作完成任务在许多环境中这种合作包括支持分布式查询分布式消息传递甚至包括认证和授权行为因为涉及通信量的多少象文件传输这样需要大流量的网络操作通常在对等点间直接发生 — 而不是通过对等点的网络 思考上面图 中的网络当对等点 A 希望知道网络中另一个对等点的位置时它就发出一个查询请求并传递给邻居这些邻居尝试满足这个请求如果这些邻居不能完全满足这个请求就将请求传递给它们的邻居以此类推 要加入网络一个对等点要找到愿意接受它为邻居的另一个对等点但是当对等点本身还不是网络的一部分时它如何找到网络中的另一个对等点呢？ 一个可能的解决方案是向这个对等点提供一个对等点列表让其检查对等点设法联系列表上的对等点直到一个或多个对等点接受它为邻居这个解决方案听起来很象点到点模型是不是？正如最初 Gnutella 用户所证明的那样这个解决方案只是一定程度上有效因为 PP 网络（尤其是 Gnutella）动态性很强任何静态列表都不太可能长期有效 进一步研究 Gnutella 这种环境中的解决方案是很有趣的Gnutella 实现首先将这样开始当其它对等点通过网络传播发送请求时Gnutella 捕获并持久地存储这些对等点的位置当这些客户机关闭后又重新启动时它试图连接每个先前标识的对等点直到找到一个或多个仍在运行 这种方法虽然自动化程度很高但是脆弱而且低效后来通过添加对从中央缓存下载活动对等点的列表的支持（请参阅参考资料以获得示例）改进了这种模式下的客户机 这种模型的一个有趣的方面是在支持对等点发现的过程中组成网络的对等点担任了非常活跃的角色正如我们即将看到的活动对等点的参与并不是必要条件 多播（multicast）模型 除了网络中的节点不必协助发现以外多播模型和网络模型很相似这种模型利用网络自身提供的特性来定位和确认对等点和资源这种技术的实现（Sun Microsystems 的 Project Jxta 是一个极佳的示例有关 Jxta的更多信息请参阅参考资料）使用 IP 多播来实现查询 不象单播（unicast） IP 数据报 — 一台主机最多只能向一台主机发送数据报多播 IP 数据报可以同时发往多台主机更重要的是发送方不必知道有多少接收方存在或者究竟有没有接收方存在发送主机只是封装消息并将它发布到网络上所有调整到适当频道（特殊 IP 地址和端口号的组合）的客户机将接收到该消息的一个副本 使用 IP 多播技术的发现通过让对等点用多播定期宣布自己的存在来工作该消息包含对等点的 TCP/IP 主机名和端口号对此消息感兴趣的对等点检测这个消息后抽取出主机名和端口号并使用这个信息与新对等点建立正常的 TCP/IP 连接 这就是多播是如何在单个子网上工作的众多子网（组成整个网络）间的路由多播通信是完全不同的并且是一个非常复杂的课题这也是基于 IP 多播的发现的主要局限没有路由器的支持基于 IP 多播的发现被局限在同一子网上的对等点之间不幸的是因特网对多播并不友好通常因特网（或大型内部网）上的发现由跨网络边界的特殊对等点将消息复制到另一个网络中来实现 结束语 PP 应用程序的对等点发现是一个有趣的话题下个月我们将研究使用 IP 多播来查找活动对等点的对等点发现的实现这个简单 PP 应用程序代码的附加部分将消除一个最大的问题 — 对等点的点到点配置 |
