JXTA
| Company type | Open-source project |
|---|---|
| Industry | Computer networking, Software |
| Founded | 2001 |
| Founder | Sun Microsystems |
| Defunct | 2010 |
| Fate | Discontinued by Oracle |
| Products | Peer-to-peer protocol framework |
JXTA (short for Juxtapose) was an open-source peer-to-peer protocol framework developed by Sun Microsystems starting in 2001. The JXTA protocols utilized XML-formatted messages to facilitate data exchange and collaboration among networked devices, independent of the underlying network topology.
Designed around open XML standards, JXTA supported implementation across multiple programming environments. Available versions included Java SE, C/C++, C#, and Java ME. Notably, the C# version depended on native C++/C bindings rather than a complete re-creation in C#.
JXTA nodes established a virtual overlay network, enabling communication even when firewalls, NAT devices, or diverse network transports were present. Each resource was assigned a unique 160-bit SHA-1 URN within the Java framework, ensuring stable identification regardless of changes in network location.
Status
In November 2010, Oracle declared its exit from the JXTA initiatives. By August 2011, there had been no announcements regarding project continuation, operational strategies, Board decisions, or plans to relicense the source code under the Apache License version 2.
Protocols in JXTA
- Peer Resolver Protocol
- Peer Information Protocol
- Rendezvous Protocol
- Peer Membership Protocol
- Pipe Binding Protocol
- Endpoint Routing Protocol
Categories of peers
JXTA distinguishes two principal peer types: edge peers and super-peers. The super-peer category is further split into rendezvous and relay peers, each fulfilling specific functions within the JXTA architecture.
- Edge peers usually have intermittent, low-bandwidth connections and are often situated behind corporate firewalls or on shared networks.
- A Rendezvous peer serves as a coordinator for peers and controls message dissemination scope, which is vital when peers operate across multiple subnets.
- A Relay peer facilitates connectivity for nodes behind firewalls or NATs by employing firewall traversal protocols such as HTTP.
Any peer that satisfies certain credential and resource criteria can assume rendezvous or relay peer roles.
Advertisements
Advertisements are XML-based documents that describe resources like peers, groups, pipes, and services within the P2P environment. The exchange of advertisements is fundamental to JXTA's communication processes.
Pipes
Pipes function as virtual communication channels for transmitting messages and data in JXTA. They operate asynchronously, are unreliable by design, and support unidirectional flow. The primary pipe types include:
- Unicast
- Uni-cast Secure
- Propagate
Peer groups
Peer groups define logical clusters and set boundaries for message propagation. Every peer is part of a default group called NetPeerGroup but can concurrently join multiple sub-groups. Role assignments may differ between groups; a peer might act as an edge peer in one group and a rendezvous peer in another.
Each group must have at least one rendezvous peer to function properly. Communication across different groups is not supported.
Rendezvous network
Rendezvous nodes employ enhanced routing techniques to facilitate effective message distribution from connected edge nodes within a loosely synchronized network.
Each node holds a Rendezvous Peer View (RPV), which is an organized sequence of recognized rendezvous peers identified by their Peer IDs. Although RPVs are not strictly consistent and may temporarily differ, they generally align over time in stable environments through periodic exchanges of randomly selected RPV segments.
When an edge node issues an Advertisement, its index is propagated to rendezvous peers using the Shared Resource Distributed Index (SRDI). This index is then routed to another rendezvous node via a Distributed Hash Table (DHT) mechanism and duplicated among neighboring peers to ensure fault tolerance.
The lookup process leverages the same DHT system to identify the rendezvous node responsible for the given index. Upon locating this node, queries are directed to the original publishing edge peer, which then establishes communication with the querying peer.
In cases where no responsible node is identified through the DHT, queries undertake a "random walk" along the RPV list—both upwards and downwards—until either resolved or terminated.