JXTA Architecture Overview (draft)

Peers

Minimal-Edge peers

That require other peers(proxy-peers) to communicate with the network and that do not route messages for other peers. (commonly devices with limited resources)

Full-Edge peers

That can participate in all JXTA protocols.

A full-featured peer can send and receive messages and will typically cache advertisements. A simple peer replies to discovery requests with information found in its cached advertisements, but it does not forward any discovery requests. In any JXTA deployment most peers are likely to be edge peers.

Super-Peers:

Rendevous peer

Used for searching resources in the network and message broadcasting.

Relay peer (aka router peers)

Peer located outside of firewall or NAT boundaries having a real IP used as a message relayer for peers behind firewalls or NAT.
The relay computer is just another PC someplace on the Internet. And the significance is that you don't need to have a server to have two computers talk to each other.
Listens on an a commonly open port for outgoing connections (typically 80).

Proxy peer

Used by minimal-edge peers to access all JXTA network functionalities.

In the case of the rendezvous peer, a firewalled peer has to have explicit knowledge of the rendezvous peer in order to contact it. In the case of the relay peer, the discovery would happen dynamically. In practice, peers often serve as both relay and rendezvous peers.

Peer identity:

• A peer has a peer name which is not required to be unique.
• A peer must have an unique ID in the network represented by an unique String. UUID is the reference ID in JXTA.
• Represented using URNs
  • (Example:) urn:jxta:uuid-59616261646162614A78746150325033F3BC76FF13C2414CBC0AB663666DA53903

Peer Groups

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.

Protocols and 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 — The discovery service is used by peer members to search for peer group resources, such as peers, peer groups, pipes and services.
• Membership Service — The membership service is used by peer members to securely establish identities and trust within a peer group. Identities allow applications and services to determine who is requesting an operation and decide whether that operation should be allowed. Applications may perform their own access control or may use the Access Service. The Peer Group definition specifies the policies by which a peer may establish an identity.
• Access Service — The access service is used to validate requests made by one peer to another. The peer receiving the request checks the requesting peer's credentials, and information about the request being made to determine if the access is permitted. [Note: not all actions within the peer group need to be checked with the Access service; only those actions which are limited to some peers need to be checked.]
• Pipe Service — The pipe service is used to create and manage pipe connections between the peer group members.
• Monitoring Service — The monitoring service is used to allow one peer to monitor other members of the same peer group.
• Resolver service
• Rendezvous service

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.
The NetPeerGroup provides all seven of these services.

IP-Less communication

• Peers communicate using their peer ID.
• Peers can broadcast messages to the whole group.

Discovery

Peers on a local TCP network discover each other through a multicast message. However, once they've discovered each other, they communicate directly over a specific port (known as the endpoint). The value of the endpoint is embedded within the PDP(Peer Discovery Protocol) messages that the peers exchange. A peer listens for connections on this port; one peer contacts another by making a connection to the second peer's endpoint.

Relay/Rendezvous peers found on the local network will pass the requests to other sub/super-networks. Statically assigning Rendezvous peers outside the known network allows connection to other peers on the Internet that can not be dynamically discovered. These Rendezvous peers are contacted by HTTP.

Public lists (still working?):

• RDV Peers: http://rdv.jxtahosts.net/cgi-bin/httpRdvsProd.cgi
• Relay Peers: http://rdv.jxtahosts.net/cgi-bin/routersProd.cgi

Advertisements:

Used for discovery.
All peers need to provide advertisements regarding their resources using XML documents for:

• Peer Advertisement – peer ID, endpoints and other attributes.
• Peer Group Advertisements – peer group ID, name, description, etc.
• Rendezvous Advertisement — describes a peer that acts as a rendezvous peer for a given peer group.

Connection routing process:

1. Computer A opens a server socket with a pipe ID of X.
2. Computer B opens a client socket with an ID of X.
3. JXTA creates a route between A and B.

The routing between A and B calculates what relays to use, or directly connects the two computers on the same network.

Firewall/NAT traversing

Prerequisites

• At least one peer in the peer group inside the firewall must be aware of at least one peer outside of the firewall.
• The peer inside and the peer outside the firewall must be aware of each other and must support a common transport (HTTP or TCP).
• The firewall, at the very least, has to allow outbound HTTP or TCP connections. Figure 4-3 depicts a typical message routing scenario through a firewall.

Traversing process:

1. A firewalled peer connects to a relay peer which he must know.
2. The relay peer acts as a proxy for the firewalled peer and passes on the firewalled peer's request throughout the network.
3. The firewalled peer keeps polling the relay peer for the answer to his request.
4. When the answer arrives, the relay peer will deliver it to the firewalled peer at it's next poll.

HTTP Proxy support:

JXTA can use the supplied jvm HTTP proxy for communication if a proxy is required by the network configuration.

• java -Dhttp.proxyHost=proxy.mycompany.com Dhttp.proxyPort=8080

Authentication

• java -Djxta.proxy.user=usr -Djxta.proxy.password=pwd

Architecture notes from "JXTA Java™ Standard Edition v2.5: Programmers Guide"

<< Peers can organize themselves into peer groups. A Peer group, loosely defined, is any set of peers that provision and leverage a common set of services for a common purpose. There are two key aspects to this definition—common services and common purpose. Two peer groups might have the same set of services, for example a chat application, but different purposes, for example politics chat and sports chat. Peer groups can be defined on almost any basis that developers or deployers choose. For the preceding example the peer group could be redefi ned as providing a chat application for multiple topics but located within an organization, for example a university department. When defining a peer group the first two questions which must always be answered are; “What peers are members of this group?”, and “What application or service are the peers cooperating to provide?”.

JXTA peers use sockets and pipes to send messages to one another. JXTA sockets are reliable bi-directional connections used for applications to communicate reliably. Pipes are an asynchronous and unidirectional message transfer mechanism used for service communication. Messages are simple XML documents whose envelope contains routing, digest, and credential information. Pipes are bound to specific endpoints, such as a TCP port and associated IP address. >>

<< Key Aspects of the JXTA Architecture:

• The use of XML documents (advertisements) to describe network resources.
• Abstraction of pipes to peers, and peers to endpoints, without reliance upon a central naming/ addressing authority such as DNS.
• A uniform peer addressing scheme (IDs).
• A decentralized search infrastructure based on Distributed Hash Table (DHT) for resource indexing.

>>

Network operations performance issue:

JXTA is considerably slower due to the verbosity of XML messages but due to the very common network access problem that it solves it's better to have slower communication than no communication at all.

Messages:

Are sent between peers using the Endpoint Service and the Pipe Service as well as JxtaSocket(commonly used) and other approaches.
The JXTA protocols define two “on-wire” representations for messages:

• XML
• Binary

JXSE uses the binary message format.

Pipes

Two modes of communication, point-to-point and propagate. JXSE also provides secure unicast pipes, a secure variant of the point-to-point pipe.

Point-to-point Pipes

Point-to-Point pipe

Connects exactly two pipe endpoints together, an input pipe on one peer receives messages sent from the output pipe of another peer. It is also possible for multiple peers to bind to a single input pipe.

Propagate Pipes

A propagate pipe connects one output pipe to multiple input pipes. Messages flow from the output pipe, the propagation source, into the input pipes.

Secure Unicast Pipes

A secure unicast pipe is a type of point-to-point pipe that provides a secure and reliable communication channel. Unidirectional pipes are a very-low level JXTA communication programming abstraction.

It is recommended that most developers use the higher-level communication abstraction provided by the JxtaSocket and JxtaBiDipipe services.

Security side-note:

Seems JXTA uses http://www.bouncycastle.org/java.html

Other features:

• dynamic discovery (even on peers having DHCP enabled)
• groups of peers
• peer group security and membership

Implementation

Relevant classes:

• JxtaServerSocket: Server socket that waits for connections from clients.
• JxtaSocket: Socket class used to create the I/O streams for both clients and servers.
• JxtaSocketInputStream: Extension of the InputStream abstract class.
• JxtaSocketOutputStream: Extension of the OutputStream abstract class.

Communication process:

Each peer has a JxtaServerSocket to handle incomming connection and uses a JxtaSocket each time it wants to initialize communication with another peer.
Once the socket is connected, each peer has two streams. One is based on OutputStream and the other is InputStream. Both streams are connected from the input of one to the output of the other.

Also note

Interesting thread pointing out JXTA features: http://code.google.com/p/ppcast/wiki/WhyJXTAFailed

XWiki JXTA implementation

JXTA XWiki Implementation