自 JXTA 1.0 推出以后，开放源代码点对点（P2P）和分布式计算团体对它给予了热情欢迎（ developerWorks 上有关 JXTA 的早期讨论，请参阅 参考资料）。在日益增长的独立开放源代码项目下汇集了众多的 JXTA 团体，这些项目的目的就是为了验证由 JXTA 平台开发小组所做出的声明：即 JXTA 可以并应该成为未来互操作的 P2P 网络应用程序的首选构建标准。
从积累的经验中学习
在最近的两年中，JXTA 平台设计小组一直在帮助 JXTA 开发团体更好地理解基本设计概念，以及在使用 JXTA 平台 API 提供的功能时的最佳实践。应用程序开发团体的反馈和经验为小组提供了宝贵的意见和建议。这些反馈来源于现实生活中的部署工作，包括对平台最初设计的局限性、API 库的笨拙或者矛盾之处的观察，以及使 JXTA 更适合于构建现实世界 P2P 应用程序的特定要求。如果不先推出一个可工作的参考实现，那么就不可能收集这些宝贵的积累经验。因此第一个版本的 JXTA 很好地达到了它的目的。
根据这些反馈意见，JXTA 平台小组将主要精力放到了 JXTA 2 的设计和实现中的一组主要目标上。表 1 显示了最主要的设计目标，以及 JXTA 2 实现如何满足这些设计目标的简要说明（对于 JXTA 1 和 JXTA 2 之间的区别给予了强调）。
表 1. JXTA2 的设计目标和实现
目标 JXTA 2 实现
在当今大多数典型的网络配置上的海量伸缩性 • JXTA 2 引入了聚集超级节点网络（rendezvous super-peer network）的概念，通过减少传播流量极大地改进了伸缩性（参见 Toward massive scalability）
• 在聚集超级节点网络中实现共享资源分布式索引（shared resource distributed index，SRDI），创建了松散一致性、故障恢复（fault resilient）、分布式散列表（参见 Shared resource distributed index）
• 显著改进了每一个节点本地和整个网络上的资源利用
• 在实验室中使用大型超级计算机模拟在非常大的 JXTA 2 网络中的交互，并保证网络的可伸缩性达到数十万个节点
提高性能 • 改进了本地节点级别和整个网络上的资源分配和重用
• 本地优化，包括对平台内存占用的严格控制，改进线程处理、消除协议堆栈中重复的多个缓存副本、提供对储存在本地缓存中的公告（advertisement）的控制、不用执行发现就可获得与管道相关联的管道公告，等等
• 网络资源改进，包括利用 TCP 连接的反向信道更好地使用现有的网络连接、用于网络地址转换（NAT ―― 见侧栏“ 网络地址转换设备”）节点的新 TCP 中继 、通过 SRDI 只传播公告的索引而不是完整的公告、引入一种节省位的二进制在线（bit-saving binary on-the-wire）协议格式，等等
• 本地公告的储存和索引现在是在一个定制的 Xindice btree 数据库上执行，比以前的基于文件系统的存储方案在性能上有了改进
• HTTP 传输现在同时支持 1.0 和 1.1，可以更有效地使用底层 TCP 连接
• 公告中增加了路由线索（routing hint）支持，从而加速了路由解析
改进的开发人员友好性 对 API 做了大量重新设计和改进，使得 API 更容易理解并具有更多的一致性。主要的 API 改变包括：
• 消息创建和处理
• 消息元素操作
• 提高了异步发现处理的灵活性
• 编程式配置器（configurator）支持
• 明确而清晰地分离开了中继、聚集、路由器和传输功能
• 统一了描述当前网络中存在的防火墙、中继和代理元素的术语
• 组 ID 的 ID 工厂 ( 以前这是一项繁重的任务，需要手工创建 )
• JxtaSocket提供了节点之间的基于流的 API，类似于 Java 平台的套接字 API
• JxtaBiDiPipe提供了双向的管道能力，用于在节点之间传递消息
改进可靠性 对节点的自适应行为进行了更改，从而改进了整个网络的可靠性（因为聚集和中继对网络可靠性来说是最关键的服务，所以大多数更改是围绕它们进行的）：
• 在聚集连接上的容错
• 在中继连接上的容错
• 聚集的动态发现和跟踪
• 中继的动态发现和跟踪
• 如果在固定的时间内没有找到聚集，则边缘节点自动成为聚集
提高可管理性 支持对节点的详细远程监视。在 JXTA 2 中内建了广泛的测试和计量能力。这是基准测试的关键，也是使网络调整和性能 / 伸缩性改进成为可能的关键。还提供了一个 GUI 监视实用程序。它标志着使 JXTA 节点更具可管理性和更容易管理这一长期计划的开始。
兼容移动 为 Java 2 mobile edition （JXME）的 JXTA 实现提供了代理能力。
迈向海量伸缩性
现实世界的网络拓扑随着时间而不断发展。它的演变常常受到外部基础设施和经济因素的影响，这些通常是软件系统设计者无法直接控制的。JXTA 1 采取了单纯的和相当理论化的方式使用底层物理网络拓扑。相反，JXTA 2 采取了更多编程式的方式设计覆盖网络，它在今天最常见的网络拓扑上可以有更高的性能和伸缩性。
JXTA 2 推出了 聚集超级节点网络的概念：动态而自适应地将 P2P 网络成员划分为边缘节点（edge peer）和聚集节点（rendezvous peer）。传播只发生在更稳定的（且成员数更少的）聚集节点中。这种限制极大地增强了伸缩性，并降低了网络范围内消息风暴或者泛洪的可能性。
让我们更深入地看一下这种新重叠网络（overlay network）的实现。
边缘节点与聚集超级节点的对比
在 JXTA 2 中，边缘节点本质上是易变的，有可能频繁地加入和退出。JXTA 2 网络中大多数节点都会是边缘节点。一个边缘节点不转发查询请求，它可能维护、也可能不维护自己的本地公告缓存。大多数边缘节点将维护一个本地缓存，并需要使用 JXME JxtaProxy的服务（有关 JXME 的更多内容请参阅 参考资料）。
虽然一些边缘节点与聚集网络直接连接，但是许多边缘节点是通过作为中继的中间节点或者 JxtaProxy连接到聚集网络的。 要参与 P2P 网络，一个边缘节点只需知道如何到达单个聚集节点。通常，一个边缘节点维护一个已知聚集节点的列表（称为 种子聚集节点），并参与新聚集节点的动态发现，这使得该节点可以故障切换到备用聚集节点，并增强整个网络的可靠性。
聚集节点一般变化较少并且更稳定（即当它们连接到网络上后，它们就停留在那里并保持连接）。可以想到，任何时候在 JXTA 网络中边缘节点的数量要比聚集节点多得多。聚集节点在本质上是直接连接节点，这意味着它们不应该需要中继或者 JxtaProxy，以连接到网络中另一个聚集节点。每一个聚集节点都是聚集超级节点网络中的成员（在特定的 JXTA 组环境中）。聚集节点把无法根据自己的索引缓存进行解析的查询转发给其他聚集节点，它们参与维护网络中所有可访问资源的一个松散一致的 分布式散列表（DHT）。每一个聚集节点维护一个网络中所有已知聚集节点的动态视图，并可以在网络拓扑改变时连接或者故障切换到另一个聚集节点。
每个 JXTA 节点都可以假定为边缘节点或者聚集节点。事实上，一个边缘节点如果不能在一个延长的时间（extended period of time）内连接到任何聚集节点，那么它可以自适应地变为一个聚集节点。网络中所有聚集节点也可以发出查询，意味着边缘节点功能实际上是聚集节点功能的一个完全子集。一般来说，在 JXTA 2 网络中应用的是自适应式和编程式的对称方法，它受底层物理网络拓扑以及定制的用户配置影响。
共享资源分布式索引
JXTA 2 网络的操作依赖于其解析分布式查询的能力（有关这一概念的更多内容，请参阅侧栏“ P2P 网络的实质”）。在 JXTA 2 中，聚集超级节点网络形成了松散一致的 DHT，从而解析分布式查询。
JXTA 2 使用了一种称为 共享资源分布式索引（shared resource distributed index SRDI） 的分布式算法，以创建并维护网络中资源的一个总体索引。在 JXTA 中，资源是用公告形式的元数据（实质上就是 XML 文档）来描述的。通过一组特定的属性，用 SRDI 在网络范围索引这些公告。维护的分布式索引类似于一个散列表，其索引的属性作为散列键，而散列值映射回包含实际公告的源节点。因而可以在聚集网络上任何地方根据这些属性进行查询。这样，通过定位具有所需公告的节点，SRDI 就可以答复在网络中的公告查询。例如，一个节点可能向具有数千个节点的网络发送叫做 “ LotteryService的管道”的查询。SRDI 可以快速地对这种查询进行解析，并使保存有“ LotteryService管道”公告的节点给出回复。
在 SRDI 中，不再需要远程发布任何公告。发布的只是储存在节点上的公告的索引。这个索引信息通过单个连接的聚集节点“推出”到 DHT（聚集超级网络）。
松散一致的 DHT
JXTA 2 网络的作用是一个持续可用的、网络范围内的、动态的、分布式的数据结构：这是一个虚拟的散列表，包含了整个 JXTA 组中所有已发布公告的索引。一个边缘节点可以在任何时候通过提供一组属性（表中的散列键）来查询散列表。该查询是由网络（实际上是聚集超级节点网络）通过将该散列键混编为所需的值（即包含所请求公告的节点）来进行解析的，如图 1 所示：
图 1. 聚集超级节点网络作为松散一致的 DHT
在图 1 中，边缘节点 1 (EP1) 创建了一个管道，并在本地储存其公告。通过 SRDI 更新这个索引，DHT 现在就知道了这个公告。之后，边缘节点 2 (EP2) 对 EP1 的管道进行查询。聚集超级节点网络解析这个查询，并通知 EP1 对该公告的请求。结果，EP1 会将所请求的公告作为响应发送给 EP2。
要创建这个 DHT，每个节点在本地缓存公告，所有本地存储的公告都已索引。索引推送到聚集节点（在任何时侯，JXTA 2 边缘节点只连接到一个聚集节点）。聚集超级节点网络维护包含混合索引的 DHT。查询总是发送到聚集节点，如图 2 所示：
图 2. 在的聚集超级节点网络（起 DHT 作用）中进行查询解析
图 2 中显示的步骤如下：
1. EP1 创建一个管道，并在本地储存其公告。
2. 在本地更新索引，所做的更改推送到已连接的聚集节点（R1）。
3. 通过 SRDI 索引的传播，接收更新的聚集节点（R1）复制新的索引信息到超级节点网络中选择的聚集节点（R3 和 R5）。（有关此选择和复制过程的更多信息，请参阅 Rendezvous peerview and RPV walker）。
4. 然后，EP2 查询 EP1 的管道。这个查询发送到与它惟一连接的聚集节点 ―― R4。
5. R4 混编查询的属性，并将请求重定向到超级节点网络中的另一个聚集节点 ―― R3。
6. 收到通过 R1 传来的 EP1 的索引更新后，R3 立即将 EP2 的请求通知给 EP1。
7. EP1 直接向 EP2 发送包含所请求的管道公告。这时，查询得到了解析。
8. 然后，EP2 可能会决定存储管道公告，循环重新开始。
至止，我们已经描述了由 JXTA 2 聚集网络维护的 DHT，它好像总是以一种完美的一致性方式维护的。这在目前是不可能的，因为在 P2P 网络中，通过相互协作来实现 DHT 的一组聚集节点可能会出现加入和退出现象（尽管不像边缘节点那样频繁）。当聚集节点离开时，它所维护的一组索引就会在一定时间内无法使用（直到可靠的节点再次发布它）。基于一种自适应性的方式，JXTA 2 可以维护一个松散一致的 DHT，它可以处理 P2P 网络中节点的易变特性。
JXTA 2 采取的方式保证了 DHT 在突然分离的网络（即由于连接节点的消失而产生的节点孤岛）以及新合并的网络（即出现了将以前分离的节点孤岛连接起来的连接节点）中也可以继续工作。JXTA 2 的方法包括了一个 聚集节点查看（rendezvous peerview，RPV) 和一个插入式聚集节点遍历器（rendezvous walker）。
RPV 和 RPV 遍历器
RPV 是由超级节点网络中每一个聚集节点维护的。RPV 是该节点的已知聚集节点列表，按各个聚集节点的惟一节点 ID 排序。在 DHT 算法中使用的散列函数在每一个节点上都是相同的，它用于确定一个（本地不能解析的）查询请求应该转发到哪一个聚集节点。
所有变得不可达的聚集节点都会从节点的 RPV 中删除。超级节点网络中每一个聚集节点都定期向其 RPV 中随机选择的聚集节点发送其已知聚集节点的
在解析查询时，散列函数是针对聚集节点自己的 RPV 执行的。因为可能有多个现有的聚集节点断开连接，或者多个新的聚集节点加入超级节点网络，所以如果散列没有立即解析这个查询，就引入一个 RPV 遍历器，并将查询转发给有限数量的其他聚集节点。这种限定范围遍历器所使用的算法被设计为“插入式的”，也可以根据特定的网络方案进行定制。图 3 解释了索引信息的冗余储存。
图 3. SRDI ――索引信息的冗余储存
在这个图中，散列函数将收到的索引信息映射到 R5。从边缘节点收到这个索引信息的聚集节点 R1 将索引信息发送给 R5，并复制给 R4 和 R6，以增加索引信息的可用性。假设 R3 收到了匹配这条存储索引的查询，那么执行的散列会将查询发送给 R3 的 RPV 中的 R5。不过，如果此时 R5 不存在，那么 RPV 将会收缩，并将原来 R5 驻留的空间关闭。这意味着以前的 R6 将成为新的 R5。
如果 R6 没有所需的索引信息，那么网络的拓扑可能有了重大的改变。在这种情况下，RPV 遍历算法就要发挥作用了。遍历器将在 RPV 列表中上下遍历以查找该信息。
我们将在下面实际配置和使用一个聚集超级节点网络。在这之前，我们需要看一看 JXTA 2 中的一些 API 和 shell 的改进。
配置器 API 的主要改进
API 的一个主要改进之处是在对自动配置的支持方面。现在终于可以使用平台 API 通过编程创建 PlatformConfig 文件（节点公告），并启动 JXTA 平台。这意味着以前令人眼花缭乱的众多用户配置参数完全可以隐匿不管。
有多个 API 用于进行自动配置，可以根据您的特定需要选用。大多数与配置相关的 API 在 net.jxta.util.config 包中。net.jxta.util.config.Configurator类是普通的包装器类，用于简化 JXTA 2 配置编程，在许多情况下它已经足够了。在内部， net.jxta.util.config.Configurator 类使用同一包中的更低级的类来完成其工作。
在即将发布的 JXTA 2.2 中（在写作本文时尚未发布），这些配置 API 将统一到一个外部的 net.jxta.ext.config包中。特定角色（如边缘节点、聚集节点、中继）的节点配置文件将进一步方便了通过编程来进行配置。
配置的核心目标是创建一个描述要启动的节点的节点公告。这个节点公告在默认情况下保存在与 PlatformConfig 文件相同的 .jxta 目录中。
为寂静启动对 JXTA 配置进行编程
为了进行我们的试验，我们需要启动总共六个 JXTA 节点，其中五个是聚集节点，一个是边缘节点。为了方便您复制这个网络，我们将在一台计算机上运行所有这六个节点。在以前，这需要花费很大的力气来描述所有需要在 JXTA GUI 中手工输入的配置参数 ―― 这种描述轻易就可以达到本文的整个长度。
为了绕过这种复杂性，我们将创建一个名为 com.ibm.devworks.jxta2.shell.ShellStarter的 starter 类。这个类将：
1. 读取命令行参数，用惟一的名称和传输参数来配置聚集节点或者边缘节点。
2. 用 net.jxta.util.config包创建节点公告，并存储它。
3. 用新的配置启动 shell。
步骤 1 和 2 只有在没有找到现有节点公告的情况下才执行。
清单 1 显示 com.ibm.devworks.jxta2.shell.ShellStarter类的部分代码。参阅 参考资料一节，可以下载完整的代码。
清单 1. 拷贝收集器中的廉价内存分配
public class ShellStarter {
private static final String TLS_PRINCIPAL_PROP = "net.jxta.tls.principal";
private static final String TLS_PASSWORD_PROP = "net.jxta.tls.password";
private static final String ADDR_SEP = ":";
private static final String PORT_PRE = "97"; ...
public ShellStarter() { }
public static void main(String[] args) throws Exception {
...
String tpFname = PlatformConfigurator.getPlatformConfigFileName();
File tpFile = new File(PlatformConfigurator.getPlatformConfigFileName());
// only perform config if not already configured
if (!tpFile.exists()) {
tcpAddress = args[1];
rdvNode = args[3];
int rdvNodeNum = Integer.parseInt(rdvNode);
myPort = Integer.parseInt(PORT_PRE + args[2] + PORT_POST);
Vector rdvList = new Vector();
if (rdvNodeNum < 10)
rdvList.add(TCP_PRE + tcpAddress + ADDR_SEP + PORT_PRE + rdvNode + PORT_POST);
pa = PlatformConfigurator.createTcpEdge( args[0], // peername "A dwPeer - " + args[0], // description tcpAddress, // ip myPort, // ports rdvList , // rdvs USER_NAME, USER_PASS );
// disable multicast
// pass in to preserve settings
TcpConfigurator tc = new TcpConfigurator(pa);
tc.setMulticastState(false); // enable incoming connection
tc.setServer(tcpAddress);
tc.setServerEnabled(true);
tc.save(pa); // save to pa only, not file
// configure the rendezvous
if (isRdv) {
// pass in to preserve rdv settings created by PlatformConfig
RdvConfigurator rdv = new RdvConfigurator(pa);
rdv.setIsRendezVous(true);
rdv.save(pa);
}
PlatformConfigurator.save(pa);
} // if config exists
System.setProperty(TLS_PRINCIPAL_PROP, USER_NAME);
System.setProperty(TLS_PASSWORD_PROP, USER_PASS);
Boot.main(args);
} }
在清单 1 中，突出显示的代码展示了如何使用 net.jxta.util.config.PlatformConfigurator 类来准备一个节点公告，该节点公告将用于寂静启动 shell 的一个实例，而无需调用 GUI 配置器。我们首先用若干命令行参数调用帮助器方法PlatformConfigurator.createTcpEdge()创建一个边缘节点。不过，边缘节点在默认情况下启用多播（multicast），因此我们要在单机环境中禁用它。我们用 net.jxta.util.config.TcpConfigurator类关闭多播状态。我们还使用同一个TcpConfigurator启用进入的 TCP 连接。最后，我们检查命令行是否指定了这是一个聚集节点。如果是的话，我们就使用net.jxta.util.config.RdvConfigurator实例将节点设置为聚集节点。还要注意 net.jxta.tls.principal 和net.jxta.tls.password系统属性的设置，以绕过登录提示。
ShellStarter的命令行使用以下的参数：
ShellStarter <peer name> <local IP or hostname> <port index> <rdv port index> [edge | rdv]
我们创建的所有边缘节点和聚集节点都运行在同一台主机上，但是它们使用不同的 TCP 端口。参数 <port index>表明节点将运行在 97?1 端口，其中“？”是索引。这使我们可以在 9701、9711、9721 等端口上配置多达 10 个节点和聚集节点。例如，要在 9711 端口上用节点名 rdv1、IP 地址 192.168.23.17 创建一个聚集节点，我们使用下面的命令行：
ShellStarter rdv1 192.168.23.17 1 99 rdv
注意使用端口索引 99 以表明这个聚集节点没有其他已知的种子聚集节点。
要在 9701 端口上创建名为 peer1、具有同一 IP 的边缘节点，并以上面的聚集节点为种子，使用以下的命令行：
ShellStarter peer1 192.168.23.17 0 1 edge
对于 rendezvous， 在 test 目录中有五个启动目录 —— 分别为 rdv1 到 rdv5。还有一个称为 peer1 的节点启动目录。每一个目录包含一个 runshell.bat 文件，它有针对 ShellStarter的相应参数。您将需要编辑这些文件以修改 IP 地址。图 4 显示了这个网络的配置。
图 4. 布置一个试验用的 JXTA 2 网络
观察 RPV 和遍历器的活动
使用 rdv命令（参见侧栏“ JXTA 2 中的新 shell 命令”），可以看到由任何一个聚集节点维护的 RPV。
rdv -rpv
作为例子，下面的代码片段显示了 rdv1 给出的结果：
rdv5
rdv4
rdv3
rdv2
RPV 顺序反映了节点的 JXTA 节点 ID 顺序。我们现在可以观察 RPV walker 的活动了。 rdv命令有一个运行字符串索引服务的选项（只用于测试和诊断）。要启动这个服务，在所有六个节点上运行下面的命令：
rdv -start
现在，在其中一个聚集节点上创建一个字符串。在我们的例子中，我们在 rdv4 上创建“treasure”：
JXTA> rdv -add treasure
您可以用下面的 list 选项来确认 rdv4 现在包含这个字符串：
JXTA> rdv -list treasure
现在，让我们看一下 RPV 遍历器的活动。在 peer1上搜索以下的字符串：
JXTA>rdv -search treasure
Sending test message
rdv has sent search query for treasure
JXTA>rdv received from : jxta://uuid-59616261646162614A78746150325
03369170C5E92004D0DB2E48AAA571741C803
found: treasure
立刻就在 rdv4上找到了 treasure 字符串。可以在 rdv4上键入 whoami 验证这个节点 ID 确实就是 rdv4。
看一下 rdv4shell 窗口，您将看到回复确实是直接从 rdv4发出的：
Replying search query= treasure
send reply sent
在其他的聚集节点上，您会看到转发这个查询的证据：
Forwarding search query= treasure
下面是所发生的过程：当查询“treasure”时，就调用聚集节点遍历器，“遍历”聚集超级节点网络。作为一台聚集节点客户机，这个请求被传递给唯一连接的聚集节点 ―― rdv1。从 rdv1 开始的“遍历”引起了对查询的传播。每一个没有“treasure”字符串的聚集节点都通过遍历器转发这个请求给其他已知的聚集节点（转发次数不超过任意设置的生存时间 / 跳数限制值 10，并受循环检测控制），直到这个请求到达 rdv4。收到这个查询后，rdv4 直接回复给 peer1。
观察 SRDI 的活动
使用 rdvshell 命令，可以容易地试验 RPV 和聚集节点的遍历机制。要实际看到 SRDI 的活动，我们可以设置 SRDI 消息日志机制的 LOG级别为 DEBUG，并引起一些 SRDI 活动（即一个节点上创建一个公告）。
为了避免来自诊断字符串索引服务的伪消息，首先要关闭这个服务。关闭从 rdv1 到 rdv5 以及 peer1 的服务：
rdv -stop
然后在每一个节点上，用 kdb命令将 SRDI 消息的 LOG级别设置为 DEBUG：
JXTA>kdb
KDB Main Menu
1 Change LOG configuration
q Quit
MAIN> 1
LOG Menu
1 Global 2 EndpointRouter
3 Endpoint 4 HTTP
5 TCP 6 TLS
7 Rendezvous 8 Discovery
9 Resolver 10 Pipe
11 Relay 12 Messengers
13 Messages 14 Quota Listener
15 SRDI 16 CM
q Quit
LOG> 15
Level [w,i,f,d,e,q or ?])> d
LOG Menu
1 Global 2 EndpointRouter
3 Endpoint 4 HTTP
5 TCP 6 TLS
7 Rendezvous 8 Discovery
9 Resolver 10 Pipe
11 Relay 12 Messengers
13 Messages 14 Quota Listener
15 SRDI 16 CM
q Quit
LOG>
现在，我们将在 peer1 上创建一个公告，它会导致 SRDI 索引信息被推送到 rdv1，并随后复制到 DHT 中。创建公告的最容易方式是创建一个新的 peergroup（实际上是一个 peergoup 公告）：
newpgrp -n supergroup
如果再看 rdv1 输出的消息，您将会看到类似于下面的 SRDI 消息：
<DEBUG 14:36:07,078 Srdi:521> Pushing deltas in group NetPeerGroup
<DEBUG 14:36:07,078 Srdi:494> waiting 30000ms before sending
deltas in group NetPeerGroup
当散列和冗余索引复制发生时，其他聚集节点可能也会收到由 rdv1 发送的其他 SRDI 消息。
从积累的经验中学习
在最近的两年中，JXTA 平台设计小组一直在帮助 JXTA 开发团体更好地理解基本设计概念，以及在使用 JXTA 平台 API 提供的功能时的最佳实践。应用程序开发团体的反馈和经验为小组提供了宝贵的意见和建议。这些反馈来源于现实生活中的部署工作，包括对平台最初设计的局限性、API 库的笨拙或者矛盾之处的观察，以及使 JXTA 更适合于构建现实世界 P2P 应用程序的特定要求。如果不先推出一个可工作的参考实现，那么就不可能收集这些宝贵的积累经验。因此第一个版本的 JXTA 很好地达到了它的目的。
根据这些反馈意见，JXTA 平台小组将主要精力放到了 JXTA 2 的设计和实现中的一组主要目标上。表 1 显示了最主要的设计目标，以及 JXTA 2 实现如何满足这些设计目标的简要说明（对于 JXTA 1 和 JXTA 2 之间的区别给予了强调）。
表 1. JXTA2 的设计目标和实现
目标 JXTA 2 实现
在当今大多数典型的网络配置上的海量伸缩性 • JXTA 2 引入了聚集超级节点网络（rendezvous super-peer network）的概念，通过减少传播流量极大地改进了伸缩性（参见 Toward massive scalability）
• 在聚集超级节点网络中实现共享资源分布式索引（shared resource distributed index，SRDI），创建了松散一致性、故障恢复（fault resilient）、分布式散列表（参见 Shared resource distributed index）
• 显著改进了每一个节点本地和整个网络上的资源利用
• 在实验室中使用大型超级计算机模拟在非常大的 JXTA 2 网络中的交互，并保证网络的可伸缩性达到数十万个节点
提高性能 • 改进了本地节点级别和整个网络上的资源分配和重用
• 本地优化，包括对平台内存占用的严格控制，改进线程处理、消除协议堆栈中重复的多个缓存副本、提供对储存在本地缓存中的公告（advertisement）的控制、不用执行发现就可获得与管道相关联的管道公告，等等
• 网络资源改进，包括利用 TCP 连接的反向信道更好地使用现有的网络连接、用于网络地址转换（NAT ―― 见侧栏“ 网络地址转换设备”）节点的新 TCP 中继 、通过 SRDI 只传播公告的索引而不是完整的公告、引入一种节省位的二进制在线（bit-saving binary on-the-wire）协议格式，等等
• 本地公告的储存和索引现在是在一个定制的 Xindice btree 数据库上执行，比以前的基于文件系统的存储方案在性能上有了改进
• HTTP 传输现在同时支持 1.0 和 1.1，可以更有效地使用底层 TCP 连接
• 公告中增加了路由线索（routing hint）支持，从而加速了路由解析
改进的开发人员友好性 对 API 做了大量重新设计和改进，使得 API 更容易理解并具有更多的一致性。主要的 API 改变包括：
• 消息创建和处理
• 消息元素操作
• 提高了异步发现处理的灵活性
• 编程式配置器（configurator）支持
• 明确而清晰地分离开了中继、聚集、路由器和传输功能
• 统一了描述当前网络中存在的防火墙、中继和代理元素的术语
• 组 ID 的 ID 工厂 ( 以前这是一项繁重的任务，需要手工创建 )
• JxtaSocket提供了节点之间的基于流的 API，类似于 Java 平台的套接字 API
• JxtaBiDiPipe提供了双向的管道能力，用于在节点之间传递消息
改进可靠性 对节点的自适应行为进行了更改，从而改进了整个网络的可靠性（因为聚集和中继对网络可靠性来说是最关键的服务，所以大多数更改是围绕它们进行的）：
• 在聚集连接上的容错
• 在中继连接上的容错
• 聚集的动态发现和跟踪
• 中继的动态发现和跟踪
• 如果在固定的时间内没有找到聚集，则边缘节点自动成为聚集
提高可管理性 支持对节点的详细远程监视。在 JXTA 2 中内建了广泛的测试和计量能力。这是基准测试的关键，也是使网络调整和性能 / 伸缩性改进成为可能的关键。还提供了一个 GUI 监视实用程序。它标志着使 JXTA 节点更具可管理性和更容易管理这一长期计划的开始。
兼容移动 为 Java 2 mobile edition （JXME）的 JXTA 实现提供了代理能力。
迈向海量伸缩性
现实世界的网络拓扑随着时间而不断发展。它的演变常常受到外部基础设施和经济因素的影响，这些通常是软件系统设计者无法直接控制的。JXTA 1 采取了单纯的和相当理论化的方式使用底层物理网络拓扑。相反，JXTA 2 采取了更多编程式的方式设计覆盖网络，它在今天最常见的网络拓扑上可以有更高的性能和伸缩性。
JXTA 2 推出了 聚集超级节点网络的概念：动态而自适应地将 P2P 网络成员划分为边缘节点（edge peer）和聚集节点（rendezvous peer）。传播只发生在更稳定的（且成员数更少的）聚集节点中。这种限制极大地增强了伸缩性，并降低了网络范围内消息风暴或者泛洪的可能性。
让我们更深入地看一下这种新重叠网络（overlay network）的实现。
边缘节点与聚集超级节点的对比
在 JXTA 2 中，边缘节点本质上是易变的，有可能频繁地加入和退出。JXTA 2 网络中大多数节点都会是边缘节点。一个边缘节点不转发查询请求，它可能维护、也可能不维护自己的本地公告缓存。大多数边缘节点将维护一个本地缓存，并需要使用 JXME JxtaProxy的服务（有关 JXME 的更多内容请参阅 参考资料）。
虽然一些边缘节点与聚集网络直接连接，但是许多边缘节点是通过作为中继的中间节点或者 JxtaProxy连接到聚集网络的。 要参与 P2P 网络，一个边缘节点只需知道如何到达单个聚集节点。通常，一个边缘节点维护一个已知聚集节点的列表（称为 种子聚集节点），并参与新聚集节点的动态发现，这使得该节点可以故障切换到备用聚集节点，并增强整个网络的可靠性。
聚集节点一般变化较少并且更稳定（即当它们连接到网络上后，它们就停留在那里并保持连接）。可以想到，任何时候在 JXTA 网络中边缘节点的数量要比聚集节点多得多。聚集节点在本质上是直接连接节点，这意味着它们不应该需要中继或者 JxtaProxy，以连接到网络中另一个聚集节点。每一个聚集节点都是聚集超级节点网络中的成员（在特定的 JXTA 组环境中）。聚集节点把无法根据自己的索引缓存进行解析的查询转发给其他聚集节点，它们参与维护网络中所有可访问资源的一个松散一致的 分布式散列表（DHT）。每一个聚集节点维护一个网络中所有已知聚集节点的动态视图，并可以在网络拓扑改变时连接或者故障切换到另一个聚集节点。
每个 JXTA 节点都可以假定为边缘节点或者聚集节点。事实上，一个边缘节点如果不能在一个延长的时间（extended period of time）内连接到任何聚集节点，那么它可以自适应地变为一个聚集节点。网络中所有聚集节点也可以发出查询，意味着边缘节点功能实际上是聚集节点功能的一个完全子集。一般来说，在 JXTA 2 网络中应用的是自适应式和编程式的对称方法，它受底层物理网络拓扑以及定制的用户配置影响。
共享资源分布式索引
JXTA 2 网络的操作依赖于其解析分布式查询的能力（有关这一概念的更多内容，请参阅侧栏“ P2P 网络的实质”）。在 JXTA 2 中，聚集超级节点网络形成了松散一致的 DHT，从而解析分布式查询。
JXTA 2 使用了一种称为 共享资源分布式索引（shared resource distributed index SRDI） 的分布式算法，以创建并维护网络中资源的一个总体索引。在 JXTA 中，资源是用公告形式的元数据（实质上就是 XML 文档）来描述的。通过一组特定的属性，用 SRDI 在网络范围索引这些公告。维护的分布式索引类似于一个散列表，其索引的属性作为散列键，而散列值映射回包含实际公告的源节点。因而可以在聚集网络上任何地方根据这些属性进行查询。这样，通过定位具有所需公告的节点，SRDI 就可以答复在网络中的公告查询。例如，一个节点可能向具有数千个节点的网络发送叫做 “ LotteryService的管道”的查询。SRDI 可以快速地对这种查询进行解析，并使保存有“ LotteryService管道”公告的节点给出回复。
在 SRDI 中，不再需要远程发布任何公告。发布的只是储存在节点上的公告的索引。这个索引信息通过单个连接的聚集节点“推出”到 DHT（聚集超级网络）。
松散一致的 DHT
JXTA 2 网络的作用是一个持续可用的、网络范围内的、动态的、分布式的数据结构：这是一个虚拟的散列表，包含了整个 JXTA 组中所有已发布公告的索引。一个边缘节点可以在任何时候通过提供一组属性（表中的散列键）来查询散列表。该查询是由网络（实际上是聚集超级节点网络）通过将该散列键混编为所需的值（即包含所请求公告的节点）来进行解析的，如图 1 所示：
图 1. 聚集超级节点网络作为松散一致的 DHT
在图 1 中，边缘节点 1 (EP1) 创建了一个管道，并在本地储存其公告。通过 SRDI 更新这个索引，DHT 现在就知道了这个公告。之后，边缘节点 2 (EP2) 对 EP1 的管道进行查询。聚集超级节点网络解析这个查询，并通知 EP1 对该公告的请求。结果，EP1 会将所请求的公告作为响应发送给 EP2。
要创建这个 DHT，每个节点在本地缓存公告，所有本地存储的公告都已索引。索引推送到聚集节点（在任何时侯，JXTA 2 边缘节点只连接到一个聚集节点）。聚集超级节点网络维护包含混合索引的 DHT。查询总是发送到聚集节点，如图 2 所示：
图 2. 在的聚集超级节点网络（起 DHT 作用）中进行查询解析
图 2 中显示的步骤如下：
1. EP1 创建一个管道，并在本地储存其公告。
2. 在本地更新索引，所做的更改推送到已连接的聚集节点（R1）。
3. 通过 SRDI 索引的传播，接收更新的聚集节点（R1）复制新的索引信息到超级节点网络中选择的聚集节点（R3 和 R5）。（有关此选择和复制过程的更多信息，请参阅 Rendezvous peerview and RPV walker）。
4. 然后，EP2 查询 EP1 的管道。这个查询发送到与它惟一连接的聚集节点 ―― R4。
5. R4 混编查询的属性，并将请求重定向到超级节点网络中的另一个聚集节点 ―― R3。
6. 收到通过 R1 传来的 EP1 的索引更新后，R3 立即将 EP2 的请求通知给 EP1。
7. EP1 直接向 EP2 发送包含所请求的管道公告。这时，查询得到了解析。
8. 然后，EP2 可能会决定存储管道公告，循环重新开始。
至止，我们已经描述了由 JXTA 2 聚集网络维护的 DHT，它好像总是以一种完美的一致性方式维护的。这在目前是不可能的，因为在 P2P 网络中，通过相互协作来实现 DHT 的一组聚集节点可能会出现加入和退出现象（尽管不像边缘节点那样频繁）。当聚集节点离开时，它所维护的一组索引就会在一定时间内无法使用（直到可靠的节点再次发布它）。基于一种自适应性的方式，JXTA 2 可以维护一个松散一致的 DHT，它可以处理 P2P 网络中节点的易变特性。
JXTA 2 采取的方式保证了 DHT 在突然分离的网络（即由于连接节点的消失而产生的节点孤岛）以及新合并的网络（即出现了将以前分离的节点孤岛连接起来的连接节点）中也可以继续工作。JXTA 2 的方法包括了一个 聚集节点查看（rendezvous peerview，RPV) 和一个插入式聚集节点遍历器（rendezvous walker）。
RPV 和 RPV 遍历器
RPV 是由超级节点网络中每一个聚集节点维护的。RPV 是该节点的已知聚集节点列表，按各个聚集节点的惟一节点 ID 排序。在 DHT 算法中使用的散列函数在每一个节点上都是相同的，它用于确定一个（本地不能解析的）查询请求应该转发到哪一个聚集节点。
所有变得不可达的聚集节点都会从节点的 RPV 中删除。超级节点网络中每一个聚集节点都定期向其 RPV 中随机选择的聚集节点发送其已知聚集节点的
在解析查询时，散列函数是针对聚集节点自己的 RPV 执行的。因为可能有多个现有的聚集节点断开连接，或者多个新的聚集节点加入超级节点网络，所以如果散列没有立即解析这个查询，就引入一个 RPV 遍历器，并将查询转发给有限数量的其他聚集节点。这种限定范围遍历器所使用的算法被设计为“插入式的”，也可以根据特定的网络方案进行定制。图 3 解释了索引信息的冗余储存。
图 3. SRDI ――索引信息的冗余储存
在这个图中，散列函数将收到的索引信息映射到 R5。从边缘节点收到这个索引信息的聚集节点 R1 将索引信息发送给 R5，并复制给 R4 和 R6，以增加索引信息的可用性。假设 R3 收到了匹配这条存储索引的查询，那么执行的散列会将查询发送给 R3 的 RPV 中的 R5。不过，如果此时 R5 不存在，那么 RPV 将会收缩，并将原来 R5 驻留的空间关闭。这意味着以前的 R6 将成为新的 R5。
如果 R6 没有所需的索引信息，那么网络的拓扑可能有了重大的改变。在这种情况下，RPV 遍历算法就要发挥作用了。遍历器将在 RPV 列表中上下遍历以查找该信息。
我们将在下面实际配置和使用一个聚集超级节点网络。在这之前，我们需要看一看 JXTA 2 中的一些 API 和 shell 的改进。
配置器 API 的主要改进
API 的一个主要改进之处是在对自动配置的支持方面。现在终于可以使用平台 API 通过编程创建 PlatformConfig 文件（节点公告），并启动 JXTA 平台。这意味着以前令人眼花缭乱的众多用户配置参数完全可以隐匿不管。
有多个 API 用于进行自动配置，可以根据您的特定需要选用。大多数与配置相关的 API 在 net.jxta.util.config 包中。net.jxta.util.config.Configurator类是普通的包装器类，用于简化 JXTA 2 配置编程，在许多情况下它已经足够了。在内部， net.jxta.util.config.Configurator 类使用同一包中的更低级的类来完成其工作。
在即将发布的 JXTA 2.2 中（在写作本文时尚未发布），这些配置 API 将统一到一个外部的 net.jxta.ext.config包中。特定角色（如边缘节点、聚集节点、中继）的节点配置文件将进一步方便了通过编程来进行配置。
配置的核心目标是创建一个描述要启动的节点的节点公告。这个节点公告在默认情况下保存在与 PlatformConfig 文件相同的 .jxta 目录中。
为寂静启动对 JXTA 配置进行编程
为了进行我们的试验，我们需要启动总共六个 JXTA 节点，其中五个是聚集节点，一个是边缘节点。为了方便您复制这个网络，我们将在一台计算机上运行所有这六个节点。在以前，这需要花费很大的力气来描述所有需要在 JXTA GUI 中手工输入的配置参数 ―― 这种描述轻易就可以达到本文的整个长度。
为了绕过这种复杂性，我们将创建一个名为 com.ibm.devworks.jxta2.shell.ShellStarter的 starter 类。这个类将：
1. 读取命令行参数，用惟一的名称和传输参数来配置聚集节点或者边缘节点。
2. 用 net.jxta.util.config包创建节点公告，并存储它。
3. 用新的配置启动 shell。
步骤 1 和 2 只有在没有找到现有节点公告的情况下才执行。
清单 1 显示 com.ibm.devworks.jxta2.shell.ShellStarter类的部分代码。参阅 参考资料一节，可以下载完整的代码。
清单 1. 拷贝收集器中的廉价内存分配
public class ShellStarter {
private static final String TLS_PRINCIPAL_PROP = "net.jxta.tls.principal";
private static final String TLS_PASSWORD_PROP = "net.jxta.tls.password";
private static final String ADDR_SEP = ":";
private static final String PORT_PRE = "97"; ...
public ShellStarter() { }
public static void main(String[] args) throws Exception {
...
String tpFname = PlatformConfigurator.getPlatformConfigFileName();
File tpFile = new File(PlatformConfigurator.getPlatformConfigFileName());
// only perform config if not already configured
if (!tpFile.exists()) {
tcpAddress = args[1];
rdvNode = args[3];
int rdvNodeNum = Integer.parseInt(rdvNode);
myPort = Integer.parseInt(PORT_PRE + args[2] + PORT_POST);
Vector rdvList = new Vector();
if (rdvNodeNum < 10)
rdvList.add(TCP_PRE + tcpAddress + ADDR_SEP + PORT_PRE + rdvNode + PORT_POST);
pa = PlatformConfigurator.createTcpEdge( args[0], // peername "A dwPeer - " + args[0], // description tcpAddress, // ip myPort, // ports rdvList , // rdvs USER_NAME, USER_PASS );
// disable multicast
// pass in to preserve settings
TcpConfigurator tc = new TcpConfigurator(pa);
tc.setMulticastState(false); // enable incoming connection
tc.setServer(tcpAddress);
tc.setServerEnabled(true);
tc.save(pa); // save to pa only, not file
// configure the rendezvous
if (isRdv) {
// pass in to preserve rdv settings created by PlatformConfig
RdvConfigurator rdv = new RdvConfigurator(pa);
rdv.setIsRendezVous(true);
rdv.save(pa);
}
PlatformConfigurator.save(pa);
} // if config exists
System.setProperty(TLS_PRINCIPAL_PROP, USER_NAME);
System.setProperty(TLS_PASSWORD_PROP, USER_PASS);
Boot.main(args);
} }
在清单 1 中，突出显示的代码展示了如何使用 net.jxta.util.config.PlatformConfigurator 类来准备一个节点公告，该节点公告将用于寂静启动 shell 的一个实例，而无需调用 GUI 配置器。我们首先用若干命令行参数调用帮助器方法PlatformConfigurator.createTcpEdge()创建一个边缘节点。不过，边缘节点在默认情况下启用多播（multicast），因此我们要在单机环境中禁用它。我们用 net.jxta.util.config.TcpConfigurator类关闭多播状态。我们还使用同一个TcpConfigurator启用进入的 TCP 连接。最后，我们检查命令行是否指定了这是一个聚集节点。如果是的话，我们就使用net.jxta.util.config.RdvConfigurator实例将节点设置为聚集节点。还要注意 net.jxta.tls.principal 和net.jxta.tls.password系统属性的设置，以绕过登录提示。
ShellStarter的命令行使用以下的参数：
ShellStarter <peer name> <local IP or hostname> <port index> <rdv port index> [edge | rdv]
我们创建的所有边缘节点和聚集节点都运行在同一台主机上，但是它们使用不同的 TCP 端口。参数 <port index>表明节点将运行在 97?1 端口，其中“？”是索引。这使我们可以在 9701、9711、9721 等端口上配置多达 10 个节点和聚集节点。例如，要在 9711 端口上用节点名 rdv1、IP 地址 192.168.23.17 创建一个聚集节点，我们使用下面的命令行：
ShellStarter rdv1 192.168.23.17 1 99 rdv
注意使用端口索引 99 以表明这个聚集节点没有其他已知的种子聚集节点。
要在 9701 端口上创建名为 peer1、具有同一 IP 的边缘节点，并以上面的聚集节点为种子，使用以下的命令行：
ShellStarter peer1 192.168.23.17 0 1 edge
对于 rendezvous， 在 test 目录中有五个启动目录 —— 分别为 rdv1 到 rdv5。还有一个称为 peer1 的节点启动目录。每一个目录包含一个 runshell.bat 文件，它有针对 ShellStarter的相应参数。您将需要编辑这些文件以修改 IP 地址。图 4 显示了这个网络的配置。
图 4. 布置一个试验用的 JXTA 2 网络
观察 RPV 和遍历器的活动
使用 rdv命令（参见侧栏“ JXTA 2 中的新 shell 命令”），可以看到由任何一个聚集节点维护的 RPV。
rdv -rpv
作为例子，下面的代码片段显示了 rdv1 给出的结果：
rdv5
rdv4
rdv3
rdv2
RPV 顺序反映了节点的 JXTA 节点 ID 顺序。我们现在可以观察 RPV walker 的活动了。 rdv命令有一个运行字符串索引服务的选项（只用于测试和诊断）。要启动这个服务，在所有六个节点上运行下面的命令：
rdv -start
现在，在其中一个聚集节点上创建一个字符串。在我们的例子中，我们在 rdv4 上创建“treasure”：
JXTA> rdv -add treasure
您可以用下面的 list 选项来确认 rdv4 现在包含这个字符串：
JXTA> rdv -list treasure
现在，让我们看一下 RPV 遍历器的活动。在 peer1上搜索以下的字符串：
JXTA>rdv -search treasure
Sending test message
rdv has sent search query for treasure
JXTA>rdv received from : jxta://uuid-59616261646162614A78746150325
03369170C5E92004D0DB2E48AAA571741C803
found: treasure
立刻就在 rdv4上找到了 treasure 字符串。可以在 rdv4上键入 whoami 验证这个节点 ID 确实就是 rdv4。
看一下 rdv4shell 窗口，您将看到回复确实是直接从 rdv4发出的：
Replying search query= treasure
send reply sent
在其他的聚集节点上，您会看到转发这个查询的证据：
Forwarding search query= treasure
下面是所发生的过程：当查询“treasure”时，就调用聚集节点遍历器，“遍历”聚集超级节点网络。作为一台聚集节点客户机，这个请求被传递给唯一连接的聚集节点 ―― rdv1。从 rdv1 开始的“遍历”引起了对查询的传播。每一个没有“treasure”字符串的聚集节点都通过遍历器转发这个请求给其他已知的聚集节点（转发次数不超过任意设置的生存时间 / 跳数限制值 10，并受循环检测控制），直到这个请求到达 rdv4。收到这个查询后，rdv4 直接回复给 peer1。
观察 SRDI 的活动
使用 rdvshell 命令，可以容易地试验 RPV 和聚集节点的遍历机制。要实际看到 SRDI 的活动，我们可以设置 SRDI 消息日志机制的 LOG级别为 DEBUG，并引起一些 SRDI 活动（即一个节点上创建一个公告）。
为了避免来自诊断字符串索引服务的伪消息，首先要关闭这个服务。关闭从 rdv1 到 rdv5 以及 peer1 的服务：
rdv -stop
然后在每一个节点上，用 kdb命令将 SRDI 消息的 LOG级别设置为 DEBUG：
JXTA>kdb
KDB Main Menu
1 Change LOG configuration
q Quit
MAIN> 1
LOG Menu
1 Global 2 EndpointRouter
3 Endpoint 4 HTTP
5 TCP 6 TLS
7 Rendezvous 8 Discovery
9 Resolver 10 Pipe
11 Relay 12 Messengers
13 Messages 14 Quota Listener
15 SRDI 16 CM
q Quit
LOG> 15
Level [w,i,f,d,e,q or ?])> d
LOG Menu
1 Global 2 EndpointRouter
3 Endpoint 4 HTTP
5 TCP 6 TLS
7 Rendezvous 8 Discovery
9 Resolver 10 Pipe
11 Relay 12 Messengers
13 Messages 14 Quota Listener
15 SRDI 16 CM
q Quit
LOG>
现在，我们将在 peer1 上创建一个公告，它会导致 SRDI 索引信息被推送到 rdv1，并随后复制到 DHT 中。创建公告的最容易方式是创建一个新的 peergroup（实际上是一个 peergoup 公告）：
newpgrp -n supergroup
如果再看 rdv1 输出的消息，您将会看到类似于下面的 SRDI 消息：
<DEBUG 14:36:07,078 Srdi:521> Pushing deltas in group NetPeerGroup
<DEBUG 14:36:07,078 Srdi:494> waiting 30000ms before sending
deltas in group NetPeerGroup
当散列和冗余索引复制发生时，其他聚集节点可能也会收到由 rdv1 发送的其他 SRDI 消息。
- JXTA_2_具有高性能、海量伸缩性的_P2P_网络.rar (50.2 KB)
- 下载次数: 0
分享到：
发表评论
相关推荐
人脸识别项目实战
PLC热反应炉仿真程序和报告 ,PLC; 热反应炉; 仿真程序; 报告,PLC热反应炉仿真程序报告
内容概要：本文详细介绍了 C++ 函数的基础概念及其实战技巧。内容涵盖了函数的基本结构（定义、声明、调用）、多种参数传递方式（值传递、引用传递、指针传递），各类函数类型（无参无返、有参无返、无参有返、有参有返），以及高级特性（函数重载、函数模板、递归函数）。此外，通过实际案例展示了函数的应用，如统计数组元素频次和实现冒泡排序算法。最后，总结了C++函数的重要性及未来的拓展方向。 适合人群：有一定编程基础的程序员，特别是想要深入了解C++编程特性的开发人员。 使用场景及目标：① 学习C++中函数的定义与调用，掌握参数传递方式；② 掌握不同类型的C++函数及其应用场景；③ 深入理解函数重载、函数模板和递归函数的高级特性；④ 提升实际编程能力，通过实例强化所学知识。 其他说明：文章以循序渐进的方式讲解C++函数的相关知识点，并提供了实际编码练习帮助理解。阅读过程中应当边思考边实践，动手实验有助于更好地吸收知识点。
人脸识别项目实战
内容概要：本文主要介绍了Ultra Ethernet Consortium（UEC）提出的下一代超高性能计算(HPC)和人工智能(AI)网络解决方案及其关键技术创新。文中指出，现代AI应用如大型语言模型(GPT系列)以及HPC对集群性能提出了更高需求。为了满足这一挑战，未来基于超乙太网络的新规格将采用包喷射传输、灵活数据报排序和改进型流量控制等机制来提高尾部延迟性能和整个通信系统的稳定度。同时UEC也在研究支持高效远程直接内存访问的新一代协议，确保能更好地利用现成以太网硬件设施的同时还增强了安全性。 适合人群：网络架构师、数据中心管理员、高性能运算从业人员及相关科研人员。 使用场景及目标：①为构建高效能的深度学习模型训练平台提供理论指导和技术路线；②帮助企业选择最合适的网络技术和优化现有IT基础设施；③推动整个行业内关于大规模分布式系统网络层面上的设计创新。 阅读建议：本文档重点在于展示UEC如何解决目前RDMA/RoCE所面临的问题并提出了一套全新的设计理念用于未来AI和HPC环境下的通信效率提升。在阅读时需要注意理解作者对于当前网络瓶颈分析背后的原因以及新设计方案所能带来的具体好处
（参考GUI）MATLAB道路桥梁裂缝检测.zip
pygeos-0.14.0-cp311-cp311-win_amd64.whl
人脸识别项目实战
基于Matlab的模拟光子晶体光纤中的电磁波传播特性 对模式场的分布和有效折射率的计算 模型使用有限差分时域（FDTD）方法来求解光波在PCF中的传播模式 定义物理参数、光纤材料参数、光波参数、PCF参数及几何结构等参数 有限差分时域（FDTD）方法：这是一种数值模拟方法，用于求解麦克斯韦方程，模拟电磁波在不同介质中的传播 特征值问题求解：使用eigs函数求解矩阵的特征值问题，以确定光波的传播模式和有效折射率 模式场分布的可视化：通过绘制模式场的分布图，直观地展示光波在PCF中的传播特性 程序已调通，可直接运行 ,基于Matlab模拟; 光子晶体光纤; 电磁波传播特性; 模式场分布; 有效折射率计算; 有限差分时域(FDTD)方法; 物理参数定义; 几何结构参数; 特征值问题求解; 程序运行。,基于Matlab的PCF电磁波传播模拟与特性分析
内容概要：《知识图谱与大模型融合实践研究报告》详细探讨了知识图谱和大模型在企业级落地应用的现状、面临的挑战及融合发展的潜力。首先，介绍了知识图谱与大模型的基本概念和发展历史，并对比分析了两者的优点和缺点，随后重点讨论了两者结合的可行性和带来的具体收益。接下来，报告详细讲解了两者融合的技术路径、关键技术及系统评估方法，并通过多个行业实践案例展示了融合的实际成效。最后提出了对未来的展望及相应的政策建议。 适合人群：对人工智能技术和其应用有兴趣的企业技术人员、研究人员及政策制定者。 使用场景及目标：①帮助企业理解知识图谱与大模型融合的关键技术和实际应用场景；②指导企业在实际应用中解决技术难题，优化系统性能；③推动相关领域技术的进步和发展，为政府决策提供理论依据。 其他说明：报告不仅强调了技术和应用场景的重要性，还关注了安全性和法律法规方面的要求，鼓励各界积极参与到这项新兴技术的研究和开发当中。
神经网络火焰识别，神经网络火焰识别，神经网络火焰识别，神经网络火焰识别，神经网络火焰识别
人脸识别项目实战
1、文件内容：telepathy-farstream-0.6.0-5.el7.rpm以及相关依赖 2、文件形式：tar.gz压缩包 3、安装指令： #Step1、解压 tar -zxvf /mnt/data/output/telepathy-farstream-0.6.0-5.el7.tar.gz #Step2、进入解压后的目录，执行安装 sudo rpm -ivh *.rpm 4、更多资源/技术支持：公众号禅静编程坊
本东大每日推购物推荐网站管理员和用户两个角色。管理员功能有，个人中心，用户管理，商品类型管理，商品信息管理，商品销售排行榜管理，系统管理，订单管理。 用户功能有，个人中心，查看商品，查看购物资讯，购买商品，查看订单，我的收藏，商品评论。因而具有一定的实用性。 本站是一个B/S模式系统，采用Spring Boot框架作为开发技术，MYSQL数据库设计开发，充分保证系统的稳定性。系统具有界面清晰、操作简单，功能齐全的特点，使得东大每日推购物推荐网站管理工作系统化、规范化。 关键词：东大每日推购物推荐网站；Spring Boot框架；MYSQL数据库 东大每日推购物推荐网站的设计与实现 1 1系统概述 1 1.1 研究背景 1 1.2研究目的 1 1.3系统设计思想 1 2相关技术 3 2.1 MYSQL数据库 3 2.2 B/S结构 3 2.3 Spring Boot框架简介 4 3系统分析 4 3.1可行性分析 4 3.1.1技术可行性 5 3.1.2经济可行性 5 3.1.3操作可行性 5 3.2系统性能分析 5 3.2.1 系统安全性 5 3.2.2 数据完整性 6 3.3系统界面
二叉树实现。平衡二叉树（Balanced Binary Tree）是一种特殊的二叉树，其特点是树的高度（depth）保持在一个相对较小的范围内，以确保在进行插入、删除和查找等操作时能够在对数时间内完成。平衡二叉树的主要目的是提高二叉树的操作效率，避免由于不平衡而导致的最坏情况（例如，形成链表的情况）。本资源是使用C语言编程设计实现的平衡二叉树的源代码。
基于扩张状态观测器eso扰动补偿和权重因子调节的电流预测控制，相比传统方法，增加了参数鲁棒性 降低电流脉动，和误差 基于扩张状态观测器eso补偿的三矢量模型预测控制 ,基于扩张状态观测器; 扰动补偿; 权重因子调节; 电流预测控制; 参数鲁棒性; 电流脉动降低; 误差降低; 三矢量模型预测控制,基于鲁棒性增强和扰动补偿的电流预测控制方法
永磁同步电机全速域控制高频方波注入法、滑模观测器法SMO、加权切矢量控制Simulink仿真模型 低速域采用高频方波注入法HF，高速域采用滑膜观测器法SMO，期间采用加权形式切 送前方法 1、零低速域，来用无数字滤波器高频方波注入法， 2.中高速域采用改进的SMO滑模观测器，来用的是sigmoid函数，PLL锁相环 3、转速过渡区域采用加权切法 该仿真各个部分清晰分明，仿真波形效果良好内附详细控制方法资料lunwen 带有参考文献和说明文档，仿真模型 ,核心关键词： 1. 永磁同步电机; 2. 全速域控制; 3. 高频方波注入法; 4. 滑模观测器法SMO; 5. 加权切换矢量控制; 6. Simulink仿真模型; 7. 零低速域控制; 8. 中高速域控制; 9. 转速过渡区域控制; 10. 仿真波形效果; 11. 详细控制方法资料; 12. 参考文献和说明文档。,永磁同步电机多域控制策略的仿真研究
Buck变器二阶LADRC线性自抗扰控制matlab仿真 包括电压电流双闭环和ladrc控制外环加电流内环控制两种 并进行了对比，ladrc控制超调更小，追踪更快 参考文献 版本为2018b ,关键词：Buck变换器；二阶LADRC；线性自抗扰控制；Matlab仿真；电压电流双闭环；LADRC控制外环；电流内环控制；对比；超调；追踪；2018b版本。,Matlab仿真二阶LADRC控制的Buck变换器:外环LADRC+内环电流控制对比