JXTA技术精要

需积分: 0 65 浏览量更新于2024-07-23 收藏 940KB PDF 举报

"JXTA in a Nutshell" 是一本由 Li Gong、Scott Oaks 和 Bernard Traversat 合著的 O'Reilly 出版的技术书籍，专注于介绍 JXTA（Java XML Tunneling Protocol）技术，该书出版于2002年。 JXTA 是一个开放源代码的网络协议栈，由 Sun Microsystems 在2001年推出，其目标是提供一种P2P（peer-to-peer）计算模型，允许设备之间进行通信和协作，而无需中心服务器。JXTA 技术基于 XML，使得不同平台和设备间的互操作性成为可能，支持各种服务，如广告、发现、管道和身份管理等。本书的内容可能涵盖了以下几个关键知识点： 1. **JXTA 架构**：书中可能详细介绍了 JXTA 的核心组件，如 Peer Group（对等组）、Rendezvous（会合点）和 Advertisements（广告），这些都是构建 P2P 网络的基础。 2. **P2P 通信**：JXTA 提供了 P2P 网络中的节点发现和连接机制，读者可以学习如何在没有中央服务器的情况下实现设备间的通信。 3. **XML 应用**：JXTA 使用 XML 来编码和交换信息，这使得数据的标准化和解析变得简单，同时增强了跨平台兼容性。 4. **管道(Pipes)**：JXTA 管道是一种通信机制，用于在对等节点间传输数据。书中可能详细解释了管道的工作原理和使用场景。 5. **身份与安全**：JXTA 提供了身份验证和安全框架，可能包括证书管理、加密和签名，以保护 P2P 网络中的数据安全。 6. **开发实践**：作为一本实用指南，书中很可能包含了编写 JXTA 应用程序的实例和教程，帮助开发者快速上手并理解 JXTA API。 7. **应用案例**：可能会有实际应用的例子，比如分布式文件共享、协同编辑或物联网(IoT)设备之间的通信，来展示 JXTA 在实际项目中的运用。 8. **版本和社区**：书中可能还提到了当时的 JXTA 社区和开发工具，以及如何参与到 JXTA 开源项目中，获取最新版本和更新。此外，O'Reilly 出版社以其“Nutshell”系列而闻名，这些手册通常以紧凑、实用和深入的方式呈现技术内容，因此这本书可能提供了丰富的示例和技巧，帮助读者深入理解 JXTA 并快速应用到实践中。虽然这本书是英文版，但对有一定英语基础的 IT 专业人士来说，它是一本有价值的参考资料，可以帮助他们掌握 JXTA 技术，从而在分布式系统和 P2P 应用领域中取得进展。

JXTA>

whoami

<Peer>Test Shell 1</Peer>

<PeerId>urn:jxta:uuid-

59616261646162614A78746159325933A69CA85997D6433D82BDA4A4D0953A

C603</PeerId>

<TransportAddress>jxtatls://uuid-

59616261646162614A78746159325933A69CA8599

7D6433D82BDA4A4D0953AC603/TlsTransport/jxta-

WorldGroup</TransportAddress>

<TransportAddress>jxta://uuid-

59616261646162614A78746159325933A69CA8599

7D6433D82BDA4A4D0953AC603/</TransportAddress>

<TransportAddress>http://JxtaHttpClientuuid-

59616261646162614A787461593259

33A69CA85997D6433D82BDA4A4D0953AC603/</TransportAddress>

The peer ID is unique across all JXTA peers. The transport addresses contain the information

about how the peer may be contacted.

You can discover a peer explicitly using its peer ID like this:

JXTA> peers -p

jxta://59616261646162614A78746150325033D13E08EF231549AD99C79

97EAAC80A50000000000000000000000000000000000000000000000000000

00000301

This technique is easier to imagine programatically, where you wouldn’t have to type in the entire

string. You can, for example, save a peer ID and use it in later sessions as the default peer to

provide a service (assuming that the program can handle the fact that the default peer may no

longer be available); in fact, peer IDs are often saved by the JXTA platform itself when it

performs caching.

Peers keep configuration information within their current directory. If you want to start a second

instance of the shell on the same machine, you cannot do so from the same directory. Instead, you

must follow the instructions on advanced configuration that we give later in this chapter.

2.4 Peergroups

Peers self-organize into groups. JXTA does not define what these groups are, nor why they exist:

the JXTA framework supports the creation of groups and the definition of group membership, but

it is up to cooperating peers to define groups, join groups, and leave groups. Among other

purposes, peergroups serve to:

Define a set of services and resources

In order to participate in an auction, a peer must find a JXTA peergroup that provides an

auction service. The peer must join that group; only peers that have joined the group can

use the services available in the group.

There are a number of important resources that exist within each peergroup. A service is a

specific type of JXTA resource. A peer that wants to use the resources of a particular

peergroup must join that peergroup. Similarly, peers can communicate only with each

other if they have joined the same group (although, as we’ll see, all peers belong to the

NetPeerGroup, so they can always communicate with each other).

Provide a secure region

Because of their membership requirement, peergroups form an entity with a logical

boundary. Peergroups may strongly enforce a membership requirement so that the

boundaries define a secure environment as well: content within a peergroup can be

accessed only by peers belonging to that group, so a peergroup with strict membership

requirements can secure its content from the rest of the world.

The underlying network topologies of peers within a peergroup do not necessarily reflect

physical network boundaries, such as those imposed by routers and firewalls. A

peergroup can consist of peers on completely disparate networks. Peergroups virtualize

the notion of routers and firewalls, subdividing the network in secure regions without

respect to actual physical network boundaries.

Create scoping

Peergroups are typically formed and self-organized based on the mutual interest of peers.

No particular rules are imposed on how peergroups are formed. Peers with the same

interests tend to join the same peergroups. Therefore, the abstract regions defined by a

peergroup provide an implicit scoping mechanism for peergroup operations. Peergroup

boundaries delimit the search horizon when looking for peergroup resources. Peergroup

scopes help scalability by reducing network traffic explosion within the JXTA network.

Messages within a peergroup are propagated only to peers that are members of the

peergroup.

Create a monitoring environment

Peergroups enable peers to monitor members, interactions (traffic introspection,

accountability, traceability, etc.).

The JXTA platform defines two kinds of peergroups:

The NetPeerGroup

This is the default peergroup a peer joins after booting the JXTA network; it is sometimes

called the World Peergroup. Configuration of the NetPeerGroup is typically done by the

administrator in charge of the network domain on which the peer is located. The

NetPeerGroup defines the initial scope of operations of a peer and the default services it

provides.

User peergroups

Users (and applications) can create new peergroups with their own set of customized

services and membership policies. User peergroup services are created by either cloning

and extending the NetPeerGroup services or by creating new ones. All user peergroups

are subsets of the NetPeerGroup.

All peers are automatically members of the NetPeerGroup peergroup; they do not need to take any

special actions to join the group, and they cannot leave the group. Peers may opt to join and leave

other groups at will. In order to join a group, a peer must discover the group and then ask to join it.

Depending on the group, the peer may have to present authentication credentials, and the group

will vote on the peer’s application.

Let’s see how this all works in the context of the shell. When the shell starts, it automatically joins

the NetPeerGroup. One way that you can find the group that a shell belongs to is with the

whoami -g command:

JXTA>

whoami -g

<PeerGroup>NetPeerGroup</PeerGroup>

<Description>NetPeerGroup by default</Description>

<PeerGroupId>urn:jxta:jxta-NetGroup</PeerGroupId>

Any peer can create a peergroup. Peergroups are typically composed of peers that have either a

common set of interests (e.g., music or baseball peergroups) or that interact with each other to

exchange contents.

2.4.1 Peergroup Services

Peergroups allow us to introduce the notion of protocols and services in the JXTA platform. A

peergroup provides a set of services that peers can utilize. The JXTA platform defines seven core

services:

• Discovery service

• Membership service

• Access service

• Pipe service

•

Resolver service

•

Monitoring service (sometimes called the "purines" service)

• Rendezvous service

This set of core services is used to "seed" the peer so it can discover and find enough resources to

support itself. The NetPeerGroup services provide sufficient functionality for allowing this

dynamic bootstrapping mechanism. The core services were selected to enable a peer to have

enough functionality to create and join a large variety of peergroups:

• The membership service is necessary to enforce a policy for new peers to join a

peergroup.

• The discovery service is necessary for a peer to discover new network resources (so a

peer can expand its capabilities).

•

The resolver service provides the essential infrastructure for services to communicate.

•

The pipe service provides the ability for one or more peers to exchange messages.

User peergroups can extend, replace, or add new services, allowing a variety of peergroups to be

created.

A peergroup does not need to provide all of these services; it can provide only those that are

necessary to support the peers within the group. Most peergroups, however, will provide at least a

membership service. Since peers are always members of the NetPeerGroup, they can always

obtain these services from the NetPeerGroup.

The NetPeerGroup provides all seven of these services. In general, each of these services defines a

specific protocol used to access the service.

2.4.2 Creating Peergroups

Any peer can create a peergroup. The shell creates a peergroup with these commands:

JXTA>

mygroupadv = mkadv -g mygroup

JXTA>mkpgrp -d mygroupadv

The first of these commands creates an advertisement (

mygroupadv

) of a new group with a

symbolic name of mygroup (advertisements are discussed in more detail later in this chapter).

The

mkpgrp

command actually creates the group.

When you create a group in this manner, information about the group is broadcast to other peers

using a discovery protocol that we discuss in the next section. In general, a peer can find a

peergroup in two ways:

• When a new group is created, an announcement of that group is published, and peers who

are searching will discover the new group.

•

A peer can initiate discovery to find groups. In the shell, this is accomplished with the

groups -r

command:

• JXTA>

groups -r

group discovery message sent

You can see which groups the shell knows about by using the groups command:

JXTA>

groups

group0: mygroup

group1: anothergroup

In this last example, we know about

mygroup

because that’s the group that we created; we know

about anothergroup because another peer on the network created that group and we

discovered it. Note that the NetPeerGroup does not show up in this list, even though it is also a

peergroup.

Each peergroup is uniquely identified by a unique peergroup ID. The peergroup ID is guaranteed

to be unique within the entire JXTA network.

2.4.3 Joining Groups

Once a peer has discovered or created a group, it can join the group. This entails sending an

application (with any necessary credentials) to the group and awaiting a response. The

membership service of the group will vote on the new application and send back either an

acceptance or a rejection.

A shell joins a particular group by using the join command:

JXTA>

join -d group0

Enter the identity you want to use when joining this peergroup

(nobody)

1Identity:

jra

After executing this command, the shell is a member of the group

mygroup

. A quick note about

syntax here: group0 comes from the list of groups we obtained with the groups command.

You can use the symbolic group name (e.g.,

mygroup

) to join a group only if that shell created

the group. To join a group that the shell discovered (such as anothergroup), however, you

must use the

group#

that the shell has assigned. Because the shell caches information about

groups, it might have created the group, exited, and restarted. In that case, you must also use the

group#

that the shell has assigned.

A peer can join multiple groups by executing another

join

command; the

join

command can

also be used to determine which groups the peer has joined:

JXTA>join -d group1

Enter the identity you want to use when joining this peergroup

(nobody)

1Identity:

sdo

JXTA> join

Joined group : mygroup

Joined group : anothergroup (current)

Commands that the shell executes will be associated with the current group (anothergroup);

the current group can be changed with the

chpgrp

command:

JXTA>

chpgrp mygroup

n this command, you always use the symbolic group name rather than the

group#

name. The

current group is used to find any service that the shell needs; it is also the group printed by the

whoami command.

Membership in any group created by the shell is automatic, so these examples work well when

dealing with groups created by two different shells. A shell might also discover a different group,

however: one that has membership criteria and requires the shell to present some special

credentials. Membership in such groups requires that you know how to fill out a credential

request, which is group-specific; we’ll look at how this works in Chapter 7.

2.4.4 Canceling Group Membership

A peer can cancel its membership in a group. The shell cancels its membership in a group with the

leave

command:

JXTA>

leave

This command cancels membership in the current group. You cannot leave the NetPeerGroup.

2.5 Discovery

So far, our shell does not know a lot of peers. In the JXTA world, this is not a good thing, as a

peerless JXTA application is not very useful. The first thing it must do, therefore, is find other

peers with whom it can exchange information. The process of finding other peers is called

discovery.

The process of discovery applies to any JXTA resource: peers discover other peers, and they also

discover peergroups, pipes, advertisements, and other resources. There are two ways in which

peers discover resources: peers discover resources dynamically, and they use special, statically

configured peers to tell them about JXTA resources. Discovery occurs within the context of a

peergroup: a peer attempts to discover resources within a specific peergroup.

2.5.1 Dynamic Discovery

Peers use the JXTA Peer Discovery Protocol (PDP) to discover JXTA resources dynamically. The

PDP defines the lowest-level technique that is available for peers to discover resources. On an IP

network, it consists of two parts: a multicast message that is sent on the local network and the use

of rendezvous peers to discover peers beyond the scope of the local network. Other network

bindings will behave differently, but the essential operation of the PDP is that the requesting peer

sends a message, and resources that hear the request will respond directly to the peer. Therefore, a

peer using PDP will discover all JXTA resources that are on the local network or are known by the

peer’s rendezvous peers.

The implementation of discovery is actually a feature of the peergroup in which the peer is

running. Certain peergroups may define other protocols by which peers can discover resources

within the peergroup. The PDP is implemented by the discovery service that runs within the

NetPeerGroup (and most other peergroups).

The

peers -r

command of the JXTA Shell implements the PDP; it will discover all other

JXTA peers on the local network. Before executing this command, you may want to start a shell

on another machine on your network (if you must start a second shell on the same machine as the

first, skip ahead to Section 2.6 to see how to do this).

Now in the original shell window you can execute commands to discover the second peer:

JXTA>

peers

peer0: name = Test Shell 1

JXTA>peers -r

peer discovery message sent

JXTA>

peers

peer0: name = Test Shell 1

peer1: name = Test Shell 2

If you execute the same commands from the second shell, you’ll notice that it numbers the peers

differently. The peer numbers are used only internally by the shell application; peers are not

numbered in a JXTA sense (except for their unique IDs).

It can take some time for the shell to discover other peers; executing the

peers

command

may not necessarily report all of the peers on the network until the shell has completed its

discovery process. In addition, some peers may not respond because they miss the multicast

message; no reliable network protocol is used to discover peers. On the other hand, as more peers

are added to the network, discovery is faster: that’s because when a peer responds to a discovery

message, it sends information about itself and about all other peers that it has already discovered.

2.5.2 Static Discovery Through Rendezvous Peers

There are special JXTA peers known as rendezvous peers. These peers are like landmarks: they

keep a list of peers (and other JXTA resources) that they know about, and other peers query them

for that list.

If you’ve been following along with our example, and you’re on a computer connected to the

Internet, when you first executed the

peers

command, you received a list of peers. This is

because the shell is configured to contact certain known rendezvous peers on the Internet; by

default, it will automatically contact the hosts 209.25.154.235 and 209.25.154.237. These hosts

showed up in our earlier example as peers JXTA.ORG235 and JXTA.ORG237.

These hosts are the boostrapping set of rendezvous peers for the NetPeergroup. Peers may

discover rendezvous peers dynamically and use them in place of these; the intent of the

bootstrapping rendezvous peers is to initiate the discovery process of dynamic rendezvous peers.

When the shell contacts the peer at one of these hosts, it will get back a list of all other peers that

have discovered that same rendezvous peer. Therefore, a JXTA Shell running on a machine

connected to the Internet may automatically discover many peers.

You can use the

rdvstatus

command within the shell to see if the shell has successfully

contacted a rendezvous peer:

JXTA>

rdvstatus

剩余158页未读，继续阅读

Leekwen

粉丝: 1w+
资源: 94

JXSE JXTA pdf

JXTA 三本图书

Java 代码实现了一个简单的文本编辑器-可运行

MATLAB实现基于Attention-LSTM的多特征分类预测（含完整的程序和代码详解）

基于Flask和SQLAlchemy 的简易仓库管理系统源码(期末课程设计).zip

民航网上订票系统 JAVA毕业设计 源码+数据库+论文 Vue.js+SpringBoot+MySQL.zip

JAVA项目报告-闹钟的设计与实现.pdf

毕业设计论文SpringBoot考试信息报名系统.docx

RJFireWall-maste真资源

基于Java的简易学生管理系统开发与实现

最新资源

民航网上订票系统 JAVA毕业设计源码+数据库+论文 Vue.js+SpringBoot+MySQL.zip