This material is from Chapter 2, Overview of JXTA, from the book JXTA: Java P2P Programming (ISBN: 0-672-32366-4) written by Daniel Brookshier, Darren Govoni, Navaneeth Krishnan, and Juan Carlos Soto, published by Sams Publishing.
© Copyright Pearson Education. All rights reserved.
In This Chapter
- JXTA Defines
- JXTAConcepts
- Peer and Groups
- Advertisements
- Pipe Bending Protocols
- Rendezvous Protocol
- JXTA Identifiers
- Summary
By Daniel Brookshier
Now we look at key JXTA concepts and the protocols used. In this chapter, we
will reiterate aspects of that protocol from the author's point of view and
in less formal language to ease you slowly into JXTA concepts. The JXTA protocol
specification is a formal document that describes a standard for JXTA peers and
their behavior. The goal of this chapter is to acquaint you with the concepts in
preparation for Chapter 3, "JXTA Protocols," where we will begin
covering Java API.
JXTA Defined
The following a quote is from the introduction of the JXTA protocol
specification:
The JXTA protocols are a set of six protocols that have been specifically
designed for ad hoc, pervasive, and multi-hop peer-to-peer (P2P) network
computing. Using the JXTA protocols, peers can cooperate to form self-organized
and self-configured peer groups independently of their positions in the network
(edges, firewalls), and without the need of a centralized management
infrastructure.
What this all means is that JXTA is a framework with a set of standards that
support peer-to-peer applications. JXTA is not an application, and it does not
define the type of applications you write. The protocols defined in the standard
are also not rigidly defined, so their functionality can be extended to meet
specific needs.
JXTA is made up of three distinct layers. The first is the platform. The
platform contains core functionality used by services, which are the second
layer. Services provide access to the JXTA protocols. Finally, there are
applications that use services to access the JXTA network and utilities. This
arrangement should be familiar because it is identical to a standard operating
system, where there are three layers consisting of the core operating system,
services, and applications.
JXTA adds several new concepts, such as the peer, peer group, pipe, and
endpoints. JXTA uses a new concept in peer-to-peer communication and discovery
with advertisements, which are XML documents that describe services and
information available on the JXTA network. Finally, we have various types of
identifiers used to distinguish one item or service from another.
Goals of JXTA
To begin, let's start with the goals of JXTA. The goals of JXTA are very
simple:
In essence, the goals of JXTA are to support peer-to-peer programming on any
device from a desktop computer to a PDA to a car or washing machine.
Note
JXTA is not a competitor to JINI.
Although JXTA can run on devices, such as refrigerators, but that is not the
ultimate goal—just something possible given the goals. Many new to JXTA
confuse JXTA with JINI because of the many references to devices. JXTA and JINI
have similar, but different, goals. JINI is aimed more at discovering and using
devices. JINI is also more Java-centric where JXTA specifically uses XML instead
of RMI, as does JINI. JINI was also designed to work within the bounds of a
local area network, not to interoperate on the Web and across firewalls, as does
JXTA. JINI is also more concerned with services located on a particular network,
such as a printer, for example. JXTA would more likely be used to communicate
with a software service that is not location specific.
There are also conceptual goals. These goals include the following:
Use groups to organize peers and to give context to services and
applications.
Groups use authentication and credentials to control access and/or enable
security at the group level.
Distribute information about peers and network resources throughout the
network.
Queries are distributed throughout the system.
Provide an infrastructure for routing and communications between peers.
Communication with peers behind firewalls and other barriers is a key part of
this goal.
Provide mechanisms to allow peers to monitor each other and
resources.
In addition to these goals, there are several other goals, such as
encryption, support for various communications protocols, ease of use,
stability, and performance. All of these goals were considered when creating the
JXTA protocols and the initial Java API.
Additionally, there were other goals considered by the developers and the Sun
Microsystem's managers:
Create a system that would enable any device to be added to the JXTA
network (similar to JINI).
Create a system that would enable centralized management of peers within
ISPs and corporate Internets.
Create a system that can support digital rights management. This would
foster JXTA's use in purchasing digital products, such as software, music,
movies, and other digital media. File sharing P2P applications that do not
account for digital rights will be seen as a legal liability and will be blocked
by businesses and ISPs. By respecting intellectual property and copyrights, JXTA
managers hope that JXTA will be allowed access.
Encapsulate and abstract specific core functionality so that commercial
applications can be created. In other words, enable manufactures to create
appliances or hardware to perform functions similar to traditional networking
products, such as routers, firewalls, and hubs. This enables hardware and
appliance manufacturers to profit, as well as adds industry and corporate
respectability.
The prior list has two key concepts. First, companies need to be able to feel
like they have control. Most P2P systems do not have centralized management and
are not welcome in most corporate situations. Secondly, the JXTA system needs to
produce income for more than just application developers. This means that there
needs to be hardware or hardware/software combinations that are sold by vendors.
Because Sun Microsystems is in the hardware business as well as software, this
is a very important goal.
Given all of the goals, JXTA is designed for industry acceptance,
maintainability, robustness, and can be used to fulfill almost any P2P
application concept. Because of the many goals, there is resulting complexity.
Because the system is complex and there are many methods to implement a P2P
platform, the specification is bound to change in the beginning. This chapter
was rewritten several times as the specification changed in the early months of
development of the JXTA platform.
In general, most of the following will be reasonably stable, but be aware
that some name changes or structures may occur. Based on current experience, the
differences will be minor and the following should remain mostly current for
quite some time.
XML and JXTA
XML is the basis for most of the protocol in JXTA. The key reasons are its
ability to be read by many languages and its ability to be validated. XML is
also an easy choice just because of its popularity.
Overall, XML is a good choice because it is easy to sell as a protocol. To
create a protocol that used a binary format would be more difficult to
understand, and parsers would need to be built from scratch. With XML, there are
many parsers that can be used, both commercial and free. XML is also becoming a
standard for many different industries for representing data, so mixing data
with the protocol is as simple as merging two XML documents.
There is a downside to using XML. XML is simply not a compact way to express
data. Messages written in XML will be much larger than a binary equivalent.
There are techniques that can be used, such as replacing tags with binary tokens
or compacting data, but none of these are currently employed in JXTA because
there are no widely accepted standards at this time. Consequently, the core JXTA
developers have created a simple binary message transport and have used terse
language and acronyms for tag names. Unfortunately, this means that the XML used
in JXTA is devilishly hard to learn and read.
Because some developers are not familiar with XML, Appendix B, "XML
Primer," has a short primer on XML concepts.
JXTA Concepts
Peer-to-peer networking, such as server-based networking, requires a lexicon
of concepts that need to be understood. The concepts are similar to others you
are familiar with, except that there are a few twists caused by the needs of a
P2P network. Let's look at the important definitions and concepts that will
be critical to understanding JXTA. We'll return to each of these concepts
and discuss them in more detail later in the chapter.
Peer
A peer is a virtual communications point. You can have multiple peers on a
computer or device. A peer is not the same as a user because a user may have
peers on their phone, office/home computer, or other devices. It is also
possible to have multiple peers on a single device, not necessarily an ideal
situation but good for debugging.
Because a peer is not the same as a user, applications need to abstract the
idea of user separately from peers. Any abstraction of users should be viable
when a user has access to multiple peers.
Peers are also associated with special network services that they provide. In
the reference implementation, peers can share basic services with the rest of
the network, such as rendezvous, router, gateway, or a combination. These basic
services provide search and communication services. In general, not all peers
need to enable these services, but a percentage of them are required to ensure
that other peers have access to these services. We will cover the concepts of
these services a little later in this chapter.
One Peer On One Computer
Usually only one peer resides on a single platform. We assume a communications
model where there is only one peer per device. When P2P is accomplished by
a distributed network of computers acting as peers, we get the most value
from collaboration, distributed searching, content sharing, bandwidth sharing,
distributed processing, and other P2P applications. Nevertheless, there is
nothing to preclude multiple peers from residing on a single platform or multi-CPU
device. As long as the peers can be viewed as separate entities, there should
be no problem, except for consuming extra resources. As a minimum, multiple
peers can be launched on a single computer to simulate a network for debugging.
One reason for multiple peers on a single computer is to provide a proxy
service for peers that are too small to be a JXTA client. This is true for cell
phones or other portable devices. However, with advancements in portable
devices, there is less of a need for this type of arrangement. There are cases
where you need to do this, but they should be special cases. You should also
realize that the same functionality could be created by a group of individual
peers, each peer acting as a proxy for the telephone peer.
Context switching—The number of peers you need to run are greater
than the capacity of the server. As each peer is communicated to, you need to
switch its state into active memory.
Size—How much of a peer do you allow in the server? How big of an
application? How do you constrain and manage it?
Application—What is the application? Will all customers use it? Is
there a value worth charging for?
Another possible solution that could have multiple peers is to interface to an
existing server. The peers would act as a proxy view of the server so that the
resources would be available over the P2P network. Nevertheless, this again can
be solved with a distributed system of external peers that proxy the server.
Resources can be added at will by adding more peers. A peer could also
optionally use the server directly or use a proxy peer.
The whole idea of P2P computing is to distribute resources. By creating
servers with multiple peers, you are going against JXTA and P2P philosophy. You
are also burdening yourself with all the server problems that true P2P
avoids.
Imagine true P2P solutions when faced with legacy servers or attitudes.
Refactor your old server applications using JXTA when faced with costly or
inadequate server technology.
Peer Group
A peer group is a way to group peers and to advertise specific services that
are available to group members. You can create groups, join them, and of course
resign from a group. There is also the ability to renew a membership in a group.
A group may need to limit membership for various reasons, such as secure
communications between members, privacy, or there may need to be certain
information that a user must supply before joining a group. There is an
authentication protocol specifically designed to collect information and allow
the group to determine if the information meets the requirements for
membership.
The peer group provides context to use applications and to use the
applications with other peers in the same group. For example, a peer group of
jugglers would use a chat service in the juggling group. The effect would be to
limit the chat to just those that joined the juggling group.
To further the juggling example, the group could authenticate users by
validating a membership ID from a national juggling organization. Those without
an ID would not be allowed to chat with the rest of the group, because they
could not join the group.
Another way to look at groups is as a virtual private network (VPN). A VPN
allows several computers to talk to each other without allowing the rest of the
Internet to participate. VPNs include encryption so that the group conversation
is not understandable to anyone who might eavesdrop. Peer groups also limit
access to peers, and they can also use encrypted messages.
Membership to a peer group can take several forms. The two key models are
local and remote membership services. A local membership service runs entirely
on the peer that is applying for membership. All resources and ability to
validate a user reside also on the same peer. So local membership services allow
you to join without connecting to any other peer.
Remote membership requires accessing one or more peers in the group that you
are joining. The idea is that peers that already belong to the group either have
access to resources for validating a new member. Similarly, the set of peers in
the group could query their users with the new member's application to see
if the members are willing to accept the new member.
Endpoint
The endpoint is the basic addressing method used by JXTA applications to
communicate with each other. An endpoint is an address of a peer that implements
a specific protocol of communication. A peer can have multiple endpoints and
thus can be communicated with via different protocols.
Note
Address as defined here is not
necessarily a physical address. Endpoints allow the physical address to change.
For example, in a DHCP-enabled ISP, the IP address of a computer that dials in,
is going to be a random address each time.
A simple example of an endpoint is an IP address and port. By using these
values, a stream could be opened to communicate to the target peer. However,
JXTA places a layer on top of streams called pipes (discussed in the next
section). Instead of connecting a stream to an address (represented by the
endpoint), you connect a pipe to the endpoint. The beauty of endpoints and pipes
is that you don't care what the real address is or what the best protocol
to use for a particular peer. In addition, there are other services used to
route and even forward messages. Using the pipe and endpoint abstraction
provides a lot of power and reduces the complexity of building a P2P
application.
Because pipes connect via a communications protocol, the endpoint describes
the protocol and the specific information used to connect to it. Therefore, the
endpoint can describe an HTTP, TCP, BEEP, or other supported base communications
protocol.
A peer can support one or more endpoints. By supporting more than one
protocol, the peer can use the most effective method. In other words, if two
peers are behind a firewall, they can communicate through their TCP endpoints.
When these peers communicate to peers across the firewall, which traditionally
filters everything but HTTP, they would use the HTTP protocol.
Pipe
A pipe is a virtual connection between peers. Normally, we think of
peer-to-peer communications as a single connection, but this is not always
possible. The problem is that many peers cannot connect directly because of
firewalls or other barriers. Pipes are intended as a layer over multiple
communication protocols and to support relayed communications via gateway
peers.
Pipes are a basic and important feature of JXTA. They create a very useful
paradigm that allows peers to communicate in most network situation, despite
firewalls or other barriers. Even if you do not know anything about a peer or
where it is, you will to have a mechanism to communicate with the peer via a
pipe.
Pipes are used as an abstraction to hide the fact that there may be other
peers involved along with multiple connections. Pipes can also be implemented to
be self-healing and reroute around an original peer. Self healing in important
because a peer, unlike a server, is not meant to be available 24 hours a day and
can be removed from the network at any time. The Java JXTA implementation has
several flavors of pipe. As discussed, the JXTA protocols support and encourage
different types of pipe. The following is a list of a few possible (currently
not implemented) pipes that are either part of the Java implementation or
possible additions:
Uni-directional asynchronous—This is a pipe that is only used for
communications that are in one direction. The pipe is asynchronous and messages
may arrive out of order. This is the most basic type of pipe and should be
implemented on most JXTA platforms.
Synchronous request/response—All messages sent will receive a return
message of acknowledgment. Messages arrive in the order that they were
sent.
Bulk transfer—Used to move large amounts of data.
Streaming—Used to efficiently move data in a stream similar to that
of audio, video, and other data streams, such as a stock market data
feed.
Bidirectional—A combination of two asynchronous pipes.
Uni-directional synchronous—All messages sent will receive a return
message of acknowledgment. Messages arrive in the order that they were
sent.
Unicast reliable secure pipe—All messages sent will receive a return
message of acknowledgment and the data will be encrypted.
There are two different types of addressing for pipes:
Point-to-point—Point-to-point pipes connect two different peers.
Multiple other gateway peers can be used to create the connection.
Propagate—Connects one peer to multiple destination peers. Propagate
pipes are also called wire pipes because of the project that originally
developed them. Propagate pipes can also have multiple peers involved in the
connection, including those that are endpoints in the communication.
In the current platform, the uni-directional asynchronous, unicast reliable
secure pipe, and bidirectional pipes are implemented. In addition, there is a
secure version of a unicast and reliable secure pipe.
Endpoints and Pipes
JXTA is very different from a traditional network. Most network protocols
have either no address (HTTP clients) or they have a fixed address where a URL
or IP address is used to pinpoint the clients. JXTA abstracts the idea of a
client address and calls it an endpoint.
A peer can have more than one endpoint. Peers can communicate over one or
more protocols, such as TCP and HTTP, so there are usually multiple endpoints.
This sounds strange at first because we usually deal with only one protocol in
most applications. The reason JXTA uses multiple transport protocols is to allow
a service to communicate with peers over the best method possible.
If you were behind a corporate firewall, you would use HTTP to communicate
outside the firewall and TCP to talk to peers on the local LAN behind the
firewall.
With multiple transport flexibility, you can use a specific protocol for a
specific peer and thus the best speed and response. Behind the firewall, the
speed and response is very good. Crossing the firewall, the response is poor.
Overall, you are better off than if you only used HTTP that would have
sacrificed efficiency behind the firewall.
Advertisement
An advertisement is an XML document that describes a JXTA message, peer, peer
group, or service. Advertisements follow standards for encoding, tags, and
content. The advertisement is used to exchange information about what is
available in the JXTA network.
For an example of how this would work, imagine a peer that creates a peer
group with the name Trekker Chat. The peer would publish the advertisement to
the local JXTA network. This is done with an IP multicast. In other words, any
peer in the sub-net will receive a copy of the advertisement. In addition the
advertisement is sent to the rendezvous.
Peers use a special class of peers called rendezvous peers to discover
advertisements from the rest of the network. Rendezvous peers (discussed in the
next section), store advertisements and support searches. A peer can now request
the peer group advertisement by searching for its name or other property. With
the peer group advertisement, these client peers can then instantiate and join
the Trekker Chat peer group by using the information contained in the XML. When
they're members, they can use the group context of services or locate peers
that belong to the group.
Note
Most of JXTA's advertisements are
encoded with UTF-8, which is an ASCII-preserving encoding method for Unicode
(ISO 10646). Unicode could be used, but the advertisements do not use special
language characters and foreign punctuation. Because UTF-8 is 8 bits and Unicode
is 16 bits, the halving of the size of advertisements makes a lot of sense.
The only place you should find it necessary to use full Unicode is in the
body of messages. Within messages, the encoding of the contents can be specified
as Unicode or any other character set, including UTF-8.
IE 7
Firefox 2.0
