第四章 JXTA 网络架构

网络组织

JXTA 网络是由相互连接的对等体组成的一个 Ad-Hoc 、 multi-hop 网络，具有可适应性。网络的连接是暂时的，因此，两个对等体间传送消息的路径是非确定的。对等体可是随时加入或离开 JXTA 网络；这也就导致了消息传送路径会随时变化。

而各种不同的 JXTA 应用唯一的相同的方面就是它们之间的通信是通过 JXTA 协议来实现的。网络的组织不是依靠 JXTA 框架，而实际上是通过使用四种对等体来实现的：

Minimal edge peer （此处暂译作 “ 最小边对等体 ” ）
一个最小边对等体能够发送和接收消息，但是不能为其它对等体缓存通告或路径消息。通常在设备中拥有有限资源的对等体（例如一个 PDA 或者蜂窝电话）就是最小边对等体。
Full-featured edge peer （此处暂译作 “ 完全边对等体 ” ）
一个完全边对等体既可以接收和发送消息，而典型情况下是缓存通告。它可以用它所缓存的通告来响应它所接收的发现请求，但是它不能将这个发现请求转发。在各种 JXTA 配置中大部分对等体都是边对等体。
Rendezvous peer （此处暂译作 “ 聚合对等体 ” ）
聚合对等体是一种结构对等体，它可以协助其它对等体做这些事情：消息传递、发现通告和路径，而最重要的作用是它维护一个其它结构对等体的拓扑结构图，这个拓扑结构图可以用来控制消息等的分发和传递等事务。每一个对等体组都拥有一组满足自己需要的聚合对等体。边对等体向它的聚合对等体发送搜索或发现请求，聚合对等体则响应这个请求，如果它不能回答，则按照其所维护的拓扑图向其它的聚合对等体转发这个请求。
Relay peer （此处暂译作 “ 中继对等体 ” ）
中继对等体也是一种结构对等体，它可以帮助那些无地址的（防火墙 / 内网）的对等体来转发消息。（不知道这句话该如何翻译：） A peer may request an in memory message box from a relay peer to facilitate message ralaying whenever needed.

共享资源分发索引（ SRDI ）

JXSE 支持一种共享资源分发索引（ Shared Resource Distributed Index ： SRDI ）服务，当在 JXTA 网络内的传递转发搜索请求时，这种服务可以为传递转发提供一种很有效的机制。聚合对等体为边对等体发布的通告维护着一个索引。当边对等体想要再发布一个新的通告时，它就通过 SRDI 服务把这个通告的索引送给聚合对等体。通过这种 “ 聚合对等体 - 边对等体 ” 结构，请求仅仅在聚合对等体之间传递转发。这样，可以最大减少了在搜索一个通告时所牵扯的对等体的数目。

每一个聚合对等体都有一个它所知道的对等体组中的其它聚合对等体的列表。一个聚合对等体可以从一个预定义的种子对等体中获得其它聚合对等体的信息。聚合对等体周期性地选择一些预先随机指定数目的聚合对等体，向这些聚合对等体发送自己所知道的聚合对等体的列表。聚合对等体也会周期性的清除那些总是没有响应的聚合对等体。因此，这些聚合对等体都维护着一个松散的聚合对等体的网络。

当一个对等体发布一个新通告时， SRDI 服务通过该通告的名字或者 ID 之类的关键值为其编制一个索引，并且最大减少在一个聚合对等体中存储该通告所需的数据量，然后将这个索引发送给一个聚合对等体。这个聚合对等体也将该索引再发送给它所知道的其它的聚合对等体（发送给哪些聚合对等体是通过通告索引的哈希函数计算出来的）。

询问（ Queries ）

下图显示了一个配置的示例。对等体 A 是一个边对等体，并且将对等体 R1 配置成它的聚合对等体。当对等体 A 初始化一个发现或搜索请求时，它首先将其发送给它的聚合对等体，即 R1 ，在这个例子中它也通过多播方式将其发送给同在一个子网内的其它对等体。

图 6 ：通过聚合对等体转发请求

本地网内的请求（也就是同一个子网内）在转发给同一个子网内的其它对等体时是通过广播（ broadcast ）或多播（ multicast ）方式进行的。当一个对等体接到一个请求时，如果它在自己的缓存李有请求的内容，那么它就立即响应那个发送请求的对等体。

当询问要冲出子网时，则先发送给它所连接的聚合对等体。聚合对等体试图在其缓存内先查看是否有所请求内容。如果有的话，则立即响应发送请求的对等体，而且也不再转发该请求了。

如果聚合对等体没有所请求的资源，那么就要在其它的聚合对等体中来遍历搜索包含这个资源的聚合对等体，而遍历搜索时使用到的就是一个 “ 有限范围遍历算法（ limited-rang walker algorithm ） ” 。通过使用网络地图功能来修改询问的路径，以减少询问的 TTL （译者注：此处第一次出现这个缩写，不知道是哪个专业词汇）； A hop count is used to specify the maximum number of times the request is mapped/forwarded to avoid ping-pong effects which can occur in unstable or very dynamic networks. Once the query reaches the peer, it replies directly to the originator of the query. （译者注：不知道怎么翻译这句话，大概意思是：同时也要记录在前进路劲中跳跃的次数，看它是否超过了设定的最大跳跃次数，以此来避免在不稳定的或动态的网络中容易出现的死循环）。

SRDI 使用一个 SHA1 哈希地址表，在这个表中， 160 位的地址空间被分成有序的聚合对等体的列表。当一个索引到达时，它先被哈希编码，以确定它的复制地址。然后将之复制到目标聚合对等体中。

下面的图 7 从逻辑角度向您展示了 SRDI 是如何工作的。一旦结点 A 发布了一组通告，那么一组以 SRDI 消息形式的索引便发送给它的聚合对等体， RDV1 ，这些索引便存储在 RDV1 中，然后复制（基于它们的哈希映射图）到聚合对等体 2 、 3 和 4 中去。接着结点 C 发布一个询问，要询问通告 A ，那么它就依次遍历聚合对等体 2 ，然后映射到 3 ，最后走到结点 A 。

图 7 ： SRDI 操作过程

防火墙和 NAT

防火墙后面的对等体可以直接向外面的对等体发送消息，但是外面的对等体却不能同防火墙后面的对等体建立直接的连接。在 NAT 方面，情况也是这样的。

为了使 JXTA 的对等体之间能够穿越防火墙而相互通信，必须具备下面几种情况：

对等体组中至少存在一个防火墙内的对等体能知道至少一个防火墙外的对等体。
防火墙内的对等体和防火墙外的对等体必须能知道对方，并且都支持相同的协议（ HTTP 或 TCP ）。
防火墙应该允许向外的 HTTP 或 TCP 连接。

下图向您展示了典型的通过防火墙传递消息的情况。在这种情况下， JXTA 对等体 A 和 B 想传递一个消息，但是防火墙阻止它们建立直接的连接。对等体 A 首先向对等体 C 发起连接，使用的是诸如 HTTP 这样的防火墙允许通过的协议。对等体 C 然后通过诸如 TCP/IP 协议同对等体 B 建立连接。这样，对等体 A 与 B 间就建立了一个虚拟连接。