JXTA

JXTA
Developer(s) Open source (community developed)
Stable release
2.7 / March 2011
Operating system Cross-platform
Platform Java Platform, Standard Edition, Java Platform, Micro Edition, C/C++/Microsoft .NET
Type Peer-to-peer
License Based on the Apache License
Website jxse.kenai.com (unmaintained)

JXTA (Juxtapose) is an open source peer-to-peer protocol specification begun by Sun Microsystems in 2001. The JXTA protocols are defined as a set of XML messages which allow any device connected to a network to exchange messages and collaborate independently of the underlying network topology.

As JXTA is based upon a set of open XML protocols, it can be implemented in any modern computer language. Implementations are currently available for Java SE, C/C++, C# and Java ME. The C# Version uses the C++/C native bindings and is not a complete re-implementation in its own right.

JXTA peers create a virtual overlay network which allows a peer to interact with other peers even when some of the peers and resources are behind firewalls and NATs or use different network transports. In addition, each resource is identified by a unique ID, a 160 bit SHA-1 URN in the Java binding, so that a peer can change its localization address while keeping a constant identification number.

JXTA strongly resembles Chimera.

Protocols in JXTA

Categories of peers

JXTA defines two main categories of peers: edge peers and super-peers. The super-peers can be further divided into rendezvous and relay peers. Each peer has a well defined role in the JXTA peer-to-peer model.

Any peer in a JXTA network can be a rendezvous or relay as soon as they have the necessary credentials or network/storage/memory/CPU requirements.

Advertisements

An Advertisement is an XML document which describes any resource in a P2P network (peers, groups, pipes, services, etc.). The communication in JXTA can be thought as the exchange of one or more advertisements through the network.

Pipes

Pipes are a virtual communication channel used by JXTA to exchange messages and data. Pipes are asynchronous, unreliable, and unidirectional. There are basically three types of pipes:

Peer groups

A peer group provides a scope for message propagation and a logical clustering of peers. In JXTA, every peer is a member of a default group, NetPeerGroup, but a given peer can be member of many sub-groups at the same time. A peer may play different roles in different groups; it may act as an edge peer in one group, but a rendezvous in another.

Each group should have at least one rendezvous peer and it is not possible to send messages between two groups.

Rendezvous network

The Rendezvous peers have an optimized routing mechanism which allows an efficient propagation of messages pushed by edge peers connected to them. This is achieved through the use of a loosely consistent network.

Each Rendezvous peer maintains a Rendezvous Peer View (RPV), a list of known rendezvous peers ordered by the Peer ID. There is not any mechanism to enforce the consistency of all RPVs across the JXTA network, so a given RPV can have a temporary or permanent inconsistent view of the other rendezvous peers. As soon as there is a low churn rate, that is, a stable network where peers don't join or leave too frequently, the RPV list of each peer will converge as each rendezvous peer exchange a random subset of its RPV with other rendezvous peers from time to time.

When an edge peer publishes an Advertisement, the index of this advertisement is pushed to the rendezvous through a system called Shared Resource Distributed Index (SRDI). After that, the rendezvous applies a Distributed Hash Table (DHT) function so that it can forward the index to another peer in the RPV list. For replication purposes, it will send this index to the neighbours of the chosen rendezvous peer in the RPV list.

The lookup process requires the use of the same DHT function to discover the rendezvous peer which is in charge of storing that index. Once the rendezvous peer is reached it will forward the query to the edge peer which published the advertisement and this peer will get in touch with the peer which issues the query.

If the DHT function cannot find a peer which is in charge of the advertisement then the query will be forwarded up and down the RPV list until a match is found, the query is aborted, or it reaches the limits of the RPV list. This process is called random walk.

Applications

Status

"In November 2010, Oracle officially announced its withdrawal from the JXTA projects".[1] As of August 2011, the JXTA project has not yet been continued or otherwise announced to retain operations, neither a decision was made on the assembly of its Board nor an answer by Oracle regarding a pending request to move the source-code to Apache license version 2.[1]

See also

References

  1. 1 2 Verstry, J. "Latest News". JXTA Kenai Project. Kenai. Retrieved 2 Sep 2011.

External links

This article is issued from Wikipedia - version of the 8/31/2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.