要完成有用的工作，P2P 应用程序中的对等点必须能够彼此发现对方并与对方交互。本文提供了一种基于 IP 多播的发现的实现。
在软件实体能够参与具有 P2P 应用程序特征的直接的对等交互之前，该实体必须发现将要与之交互的适当的对等点。所有可行的 P2P 体系结构都提供一种针对发现问题的解决方案。在本文我将描述其中一种机制的实现。让我们通过回顾来开始今天的讨论。再访发现 对等点发现使 P2P 应用程序中的对等点能够彼此定位以便相互之间可以交互。实现对等点发现服务有多种方法。最简单的机制是显式点到点配置。这种机制通过要求每个对等点知道所有它可能与之交互的其它对等点，并与它们相连，来进行工作。点到点配置的主要优点是简单。它的主要缺点是缺乏灵活性并且缺少扩展到对等点的大型网络的能力。
发现的另一个公共模型是使用中央目录作为中介。该模型在许多传统的、非 P2P 分布式类型的应用程序中间很流行，其优点是很好理解。对等点向中央目录注册自己的存在，并使用中央目录定位其它对等点。这种模型的主要优点是易于管理和扩展的能力。但是，其集中化设计会导致单点故障，因此它对自然力或网上冲浪人数增加所带来的危害缺乏抵御能力。
许多流行的 P2P 应用程序使用网络模型而不是中央目录，在网络模型中，单个对等点只知道局域网络上的对等点身份。每个对等点都作为那些与之相连的对等点的目录。对等点通过向相邻对等点传播目录查询并返回相关的响应来进行合作。这种模型的主要优点是没有集中化。它的主要缺点是由于传播查询耗费了大量的网络和处理能力。
上面三种机制有无数种变体。不讨论这些变体了，让我们继续前进并研究另一种发现机制。
IP 多播发现
就每个对等点维护自己的目录这点而言，多播模型类似于网络模型。但是，对等点不通过合作来实现大规模网络查询。另外，对等点利用网络本身提供的特性（IP 多播）来定位和标识其它对等点。
IP 多播是无连接和不可靠的（不象 TCP/IP 是面向连接和可靠的）。虽然它使用 IP 数据报；但是不象单播 IP 数据报那样是从一台主机发送到另一台主机，多播 IP 数据报可以同时发往多台主机。
对等点定期使用 IP 多播来宣布自己的存在。宣布包含了它们的主机名和一个用于正常通信的端口。对此消息感兴趣的对等点检测这个消息后，抽取出主机名和端口号，并使用该消息建立一个通信通道。
回顾已经足够了。让我们开始研究代码吧。
简单的客户机与服务器
我们将从一个简单的示例开始，该示例演示了两个进程如何使用 IP 多播进行通信。为了简化演示，我将分别从客户机和服务器进程这两个方面来介绍示例。P2P 应用程序通常会实现这两个进程，将它们划分为客户机或服务器并不容易。
在本例中，服务器进程进行循环并等待数据报包的到来。每接收到一个包，服务器就会向控制台打印一条简短的诊断消息。客户机角色要简单得多 — 它多播单个数据报包并退出。
清单 1 和 2 说明了这两部分是如何组合在一起的。代码中的注释说明了正在发生的事情。
清单 1. 简单服务器