在软件实体能够参与具有 p2p 应用程序特征的直接的对等交互之前，该实体必须发现将要与之交互的适当的对等点。所有可行的 p2p 体系结构都提供一种针对发现问题的解决方案。在本文我将描述其中一种机制的实现。让我们通过回顾来开始今天的讨论。再访发现 对等点发现使 p2p 应用程序中的对等点能够彼此定位以便相互之间可以交互。实现对等点发现服务有多种方法。最简单的机制是显式点到点配置。这种机制通过要求每个对等点知道所有它可能与之交互的其它对等点，并与它们相连，来进行工作。点到点配置的主要优点是简单。它的主要缺点是缺乏灵活性并且缺少扩展到对等点的大型网络的能力。
发现的另一个公共模型是使用中央目录作为中介。该模型在许多传统的、非 p2p 分布式类型的应用程序中间很流行，其优点是很好理解。对等点向中央目录注册自己的存在，并使用中央目录定位其它对等点。这种模型的主要优点是易于管理和扩展的能力。但是，其集中化设计会导致单点故障，因此它对自然力或网上冲浪人数增加所带来的危害缺乏抵御能力。
许多流行的 p2p 应用程序使用网络模型而不是中央目录，在网络模型中，单个对等点只知道局域网络上的对等点身份。每个对等点都作为那些与之相连的对等点的目录。对等点通过向相邻对等点传播目录查询并返回相关的响应来进行合作。这种模型的主要优点是没有集中化。它的主要缺点是由于传播查询耗费了大量的网络和处理能力。
上面三种机制有无数种变体。不讨论这些变体了，让我们继续前进并研究另一种发现机制。
ip 多播发现
就每个对等点维护自己的目录这点而言，多播模型类似于网络模型。但是，对等点不通过合作来实现大规模网络查询。另外，对等点利用网络本身提供的特性（ip 多播）来定位和标识其它对等点。
ip 多播是无连接和不可靠的（不象 tcp/ip 是面向连接和可靠的）。虽然它使用 ip 数据报；但是不象单播 ip 数据报那样是从一台主机发送到另一台主机，多播 ip 数据报可以同时发往多台主机。
对等点定期使用 ip 多播来宣布自己的存在。宣布包含了它们的主机名和一个用于正常通信的端口。对此消息感兴趣的对等点检测这个消息后，抽取出主机名和端口号，并使用该消息建立一个通信通道。
回顾已经足够了。让我们开始研究代码吧
简单的客户机与服务器
我们将从一个简单的示例开始，该示例演示了两个进程如何使用 ip 多播进行通信。为了简化演示，我将分别从客户机和服务器进程这两个方面来介绍示例。p2p 应用程序通常会实现这两个进程，将它们划分为客户机或服务器并不容易。
在本例中，服务器进程进行循环并等待数据报包的到来。每接收到一个包，服务器就会向控制台打印一条简短的诊断消息。客户机角色要简单得多 ? 它多播单个数据报包并退出。
清单 1 和 2 说明了这两部分是如何组合在一起的。代码中的注释说明了正在发生的事情。
清单 1. 简单服务器
public
class server
{
public
static
void
main（string [] arstring）
{
try
{
// create a multicast datagram socket for receiving ip
// multicast packets. join the multicast group at
// 230.0.0.1, port 7777.
multicastsocket multicastsocket = new multicastsocket（7777）；
inetaddress inetaddress = inetaddress.getbyname（"230.0.0.1"）；
multicastsocket.joingroup（inetaddress）；
// loop forever and receive messages from clients. print
// the received messages.
while （true）
{
byte [] arb = new byte [100]；
datagrampacket datagrampacket = new datagrampacket（arb, arb.length）；
multicastsocket.receive（datagrampacket）；
system.out.println（new string（arb））；
}
}
catch （exception exception）
{
exception.printstacktrace（）；
}
}
}
清单 2. 简单客户机
public
class client
{
public
static
void
main（string [] arstring）
{
try
{
// create a datagram package and send it to the multicast
// group at 230.0.0.1, port 7777.
byte [] arb = new byte [] {h,e,l,l,o}；
inetaddress inetaddress = inetaddress.getbyname（"230.0.0.1"）；
datagrampacket datagrampacket =
new datagrampacket（arb, arb.length, inetaddress, 7777）；
multicastsocket multicastsocket = new multicastsocket（）；
multicastsocket.send（datagrampacket）；
}
catch （exception exception）
{
exception.printstacktrace（）；
}
}
}
java.net 包中的两个类使它运行。java.net.datagrampacket 类保存了 ip 数据报包中包含的数据。java.net.multicastsocket 类创建一个调整到一个特定多播组的多播套接字。
发现组件
尽管上述示例是一个很好的 ip 多播的演示，但它没有说明实现基于 ip 多播的对等点发现需要什么。要使它有用，我们需要一个功能不仅限于发送和接收包的软件组件。理想情况下，这个组件将了解它所接收的包的源对等点，并适当地丢弃一些信息，这些信息是关于那些它认为已经消失、死亡或以其它方式离去的对等点的。
在这个新设计中，对等点是一个多播组的成员。请牢记，发送到多播组的消息会透明地路由到该组的所有成员。
设计包括两个核心类和三个接口（我使用术语“接口”似乎不太严谨 ? 在技术上是一个接口和两个抽象类）。member 类的实例是一个多播组的成员。这个类管理所有的通信细节。membermanager 类的一个实例负责了解参与多播组的其它成员。
对等点通过向多播组发送一个消息，来向属于多播组中的对等点宣布自己的存在。每个消息包含关于发送消息的对等点的信息 ? 通常是主机名和用于正常（与发现无关）通信的端口。member 类和 membermanager 类对这些消息的内容几乎一无所知。对该信息的访问权属于使用这两个类的应用程序。
有三个接口跨越了消息传递／发现层和使用它的应用程序层之间的边界。它们是 reference 抽象类、message 接口和 messagefactory 抽象类。应用程序必须提供这三个接口的实现。
reference 抽象类定义了对多播组成员的引用。membermanager 类管理一个引用集。应用程序将实现这个类的一个具体版本，它将包含应用程序所需要的任何引用逻辑。该类定义了两个方法，名称是 equalsinternal（） 和 hashcodeinternal（），并且重新定义了 equals（） 和 hashcode（） 方法来调用这些方法。它通过这样做来强制实现者为这两个关键功能提供实现 ? membermanager 依赖于它们。
message 接口定义了通过网络代码交换的消息数据的应用程序视图。应用程序将该消息看作是相对于应用程序运行范围的高级概念 ? 类似于主机名和端口的概念。网络代码希望发送一个由字节组成的包。message 接口的实现定义了如何将这些高级信息与字节相互转换。引用是信息的一个关键部分，所有消息都必须包含，因此该接口要求实现提供用于读和写 reference 的方法。
问题的最后部分是 messagefactory 抽象类。这个类定义了生成新的 message 实例的机制。深藏在 member 类内的网络代码使用一个工厂来创建从多播数据报中抽取出的数据的 message 实例。每个 messagefactory 实例拥有一个随机生成的身份，它使用这个身份来从接收的消息中滤出要发送的消息。
总之，这五个类和接口（member、membermanager、reference、message 和 messagefactory）构成了一个用于进行对等点发现的简单框架。当然，还有可以改进的空间。可以很容易地添加一种基于事件的机制，用于向感兴趣的侦听器通知成员的出现或消失。一种用于过滤所接收消息的灵活机制将很有用，但其实现却比较困难。我将这些建议留作读者的作业。
member 类
上面描述的框架的完整源代码太长了，这里就不详细展示了，所以让我们只研究 member 类的部分代码，因为其中包含了操作的大多数内容。更准确地说，操作发生在两个内部类中：memberclient 类和 memberserver 类。
请再次考虑第一个示例。它由一个发送 ip 多播数据报的客户机和一个接收数据报的服务器组成。在本例中（清单 3 和 4），两个单独的应用程序执行这两项功能。p2p 应用程序中的对等点的行为方式既象客户机又象服务器，所以我们的 p2p 应用程序应该同时包含两者才是适合的。
清单 3. memberclient 类
private
class memberclient
extends thread
{
public
void
run（）
{
try
{
while （true）
{
try
{
message message = m_messagefactory.createsendmessage（）；
reference reference = message.createreference（）；
message.writereference（reference）；
message.sync（）；
byte [] arb = message.getbytearray（）；
datagrampacket datagrampacket = new datagrampacket（arb, arb.length）；
datagrampacket.setaddress（m_inetaddress）；
datagrampacket.setport（m_nport）；
multicastsocket multicastsocket = new multicastsocket（）；
multicastsocket.send（datagrampacket）；
}
catch （ioexception ioexception）
{
ioexception.printstacktrace（）；
}
try
{
synchronized （this）
{
wait（m_nperiod）；
}
}
catch （interruptedexception interruptedexception）
{
break；
}
}
}
catch （throwable throwable）
{
throwable.printstacktrace（）；
}
}
}
清单 3 包含了 memberclient 类的源代码。象清单 1 中的客户机一样，这个客户机创建一个 multicastsocket 实例并使用它来发送一个 datagrampacket 实例。datagrampacket 实例包含一个到发送方对等点的引用，该引用是作为字节数组编码的。只要该对等点还是活动的并在运行，客户机就会每隔一段常规时间来广播这条信息。
清单 4. memberserver 类
private
class memberserver
extends thread
{
public
void
run（）
{
try
{
multicastsocket multicastsocket = new multicastsocket（m_nport）；
multicastsocket.joingroup（m_inetaddress）；
while （true）
{
message message = m_messagefactory.createreceivemessage（）；
byte [] arb = message.getbytearray（）；
datagrampacket datagrampacket = new datagrampacket（arb, arb.length）；
multicastsocket.receive（datagrampacket）；
message.sync（）；
if （m_messagefactory.ismine（message） == false）
{
reference reference = message.createreference（）；
message.readreference（reference）；
m_membermanager.addreference（reference）；
}
}
}
catch （throwable throwable）
{
throwable.printstacktrace（）；
}
}
}
memberserver 类在很多方面类似于清单 2 中的服务器。除了创建必需的代码，使用它从建立的通信（wire）上采集适当的数据报以外，这个服务器还对已编码的引用进行解码、创建消息并将消息传递到 membermanager 实例进行保管。干得不错。
该类的其余部分由用于各种特性的读方法和写方法以及用于控制该类的生命周期的 start（）和 stop（）方法组成。
p2p 应用程序
对等点发现框架完成了，剩下的所有工作就是将它集成到现有的 p2p 应用程序中去了。对原来的 p2p 应用程序的更改相对较少。
首先，在其前身中，p2p 应用程序期望在其特性文件中列出所有已知的对等点。尽管这对演示用途来说很好（请回忆上面讨论的点到点配置），并在最多至大约四个对等点的情况下运行良好，但最终它的限制还是太大了。因此，除去了在特性文件中读取和管理对等点的代码，并以使用上面的发现机制的代码取代它。
其次，因为在特性文件中枚举了对等点，看上去它们就好象持久存在了。现有的应用程序如果假定它们不会消失，有时会侥幸获得成功。但是，在p2p的真实世界中，事情更易发生变化。新的应用程序进行了重新设计，适于在对等点消失时进行更好的恢复。
更新的源代码可在参考资料中得到
文章整理：站长天空 网址：http://www.z6688.com/
以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!
