Overview of JXTA

Volatile Network

Peers may also seem to disappear and reappear. This is a very common
occurrence. Many computers are not connected to the Internet 24 hours a day.
Many computers are still connected via dialup and are only on-line part of the
day. We also have to consider wireless devices that are usually only on-line for
very short periods. A laptop or a PDA can both appear and disappear as they are
docked in and out of the network. In these cases, the peer may even seem to pop
up in a different city in a completely different network topology! Because of
the possibility of such changes, it is very important to be able to invalidate a
route and reroute connections.

Gateway Issues

One of the problems with gateways is that they could significantly increase
the time it takes for a message to be sent between two peers. If there are too
many gateways, the total time for transmitting a message could be several
minutes.

With the possibility of messages taking a very long time to transmit, there
is a huge problem with managing a user's expectation. An important number
to think about here is 200 milliseconds, which is the amount of time between
clicking a button and something happening that seems to be associated with the
button. In other words, if an action occurs 200 milliseconds or less after you
click a button, the action and its response appears to be simultaneous. If the
application's reaction to the button click takes longer than 200
milliseconds, your user is waiting. The longer a user waits, the more likely
that the user is going to think that something has gone wrong. When the user
believes that the application is not working, he or she could hit the button
again, terminate the program to try again, or perform another action that you
would like to avoid.

Any JXTA processing that is a result of a user's input to the user
interface should immediately display some kind of wait symbol or pop-up dialog
as feedback. Any area of your software that has some type of JXTA network
communications will most likely need to be in a thread separating it from the
user interface. In addition, while waiting on the JXTA network, some type of
user feedback, such as a wait dialog or a status display, is a necessity.
Applications will be more complex, and you will need much more code to make them
thread safe, but the effort is required to make your application acceptable.

JXTA Protocols

JXTA protocols are used to help peers discover each other, interact, and
manage P2P applications. The protocols are not applications in themselves and
require much more code to create something useful. The protocols hide a lot of
detail, which makes writing JXTA applications much easier than developing a P2P
applications from scratch.

JXTA defines its protocols in the JXTA Protocols Specification. The
specification describes how peers communicate and interact; it does not attempt
to describe the specifics of implementation or how to write a peer-to-peer
application. In this section, we are going just give you an overview of the
protocols and discuss related issues.

The following is a list of the JXTA protocols. We have included their
acronyms, but we use acronyms rarely in the rest of this chapter:

Peer Discovery Protocol (PDP)Allows a peer to discover other peer
advertisements (peer, group, service, or pipe). The discovery protocol is
the searching mechanism used to locate information. The protocol can find
peers, peer groups, and all other published advertisements. The advertisements
are mapped to peers, groups, and other objects, such as pipes.

Queries are made by specifying an advertisement type (peer, group, or advertisement),
an XML tag name within the advertisement, and the string to match against
the data represented by the XML tag.

Peer Resolver Protocol (PRP)Allows a peer to send a search query
to another peer. The resolver protocol is a basic communications protocol
that follows a request/response format. To use the protocol, you supply
a peer to query and a request message containing XML that would be understood
by the targeted peer. The result is a response message.

The resolver is used to support communications in the JXTA protocols like
the router and the discovery protocols. For example, the protocol is used
by the discovery protocol to send queries that represent searches for advertisements.

The resolver also allows for the propagation of queries. For example, if
a peer receives a query and does not know the answer, the resolver sends the
query to other peers. This is an interesting feature, especially because the
originating peer does not need to have any knowledge of a peer that may actually
have the result to the query.

Peer Information Protocol (PIP)Allows a peer to learn about the status
of another peer. The information protocol is used partially like ping and
partially to obtain basic information about a peer's status. The body
of a PIP message is free-formed, allowing for querying of peer-specific
information. In addition, this capability can be extended to provide a control
capability.

Peer Membership Protocol (PMP)Allows a peer to join or leave a peer
group. The protocol also supports the authentication and authorization of
peers into peer groups. The protocol has three key advertisements for authorization,
and the credential. The credential created in this protocol will used as
proof that the peer is a valid member of the group.

Pipe Binding Protocol (PBP)Is used to create the physical pipe endpoint
to a physical peer. It is used to create a communications path between one
or more peers. The protocol is primarily concerned with connecting peers
via the route(s) supplied by the peer endpoint protocol.

Rendezvous Protocol (RVP)The Rendezvous Protocol is responsible for
propagating messages within JXTA groups. The Rendezvous Protocol defines
a base protocol for peers to send and receive messages within the group
of peers and to control how messages are propagated.

Peer Endpoint Protocol (PEP)Is used to create routes to route messages
to another peer. The protocol uses gateways between peers to create a path
that consists of one or more of the pipe protocols suitable for creating
a pipe. The pipe binding protocol uses the list of peers to create the routes
between peers.

One of the more significant problems is that traditional routers and DNS
servers fail because of firewalls, proxy servers, and NAT devices. This protocol
searches for gateways that allow the barriers, such as firewalls and others,
to be traversed.

This protocol also helps when the communicating peers don't support
each other's protocols. For example, if you are connecting peer-A that
supports TCP and peer-B that only supports HTTP, the endpoint protocol would
choose either one gateway that could make the translation or multiple gateways
with multiple but compatible protocols.

We can also describe these protocols in terms of what they provide to a JXTA
application. The next list is very basic, but probably is the best way to look
at what the protocols really do.

Peer DiscoveryResource search

Peer ResolverGeneric query service

Peer InformationMonitoring

Peer MembershipSecurity

Pipe BindingAddressable messaging

RendezvousPropagation messaging

Peer EndpointRouting

In the remainder of this chapter, we will describe these concepts further. In
the following, we relate the concepts of peers, groups, and how the protocols
are associated. In Chapter 3, we will cover the concepts again, but in terms of
the Java implementation and the API.

Peers and Groups

The two primary concepts to understand about JXTA are peers and groups.
Because peers and groups are a little complicated, we will discuss each one in
detail.

Peers

As discussed earlier in the chapter, peers are individual nodes on the JXTA
network. The peer is similar to a computer on a network, except that you can run
multiple peers on a single machine. Peers can be a standard PC, a PDA, an
appliance, or even a super computer.

A Peer Is Not a User

The concept of the peer should not be confused with the concept of a user. A
peer is a node on the network. Think of a normal computer on the Internet; you
should not assume that a single person uses the computer. The computer could be
shared by a family or be a publicly used device, such as an Internet kiosk. You
also should not assume that a peer node is the only place a user will access the
P2P network. The user can access the network from home, work, or through various
devices.

In your design of services and applications, be very careful to avoid linking
the user to a peer, either permanently or for long periods. Sometimes, you can
link a user to a peer, but always be able to log the user off and log in
another.

One of the many things you need to manage in a P2P application is identity.
The peer is associated with the user in many respects, so for now we will
discuss this in terms of a peer. You should create an authentication system
where multiple peers could be aggregated as a single user.

The types of things you should manage are authenticating the peer's
rights to use services. The identity of the peer in JXTA is a credential. The
credential is used throughout the system to ensure that certain operations have
the correct permissions. The credential is officially created when a peer joins
a group. The credential can also simply be some type of token created ahead of
time and presented as part of the joining process. The group recognizes the
credential during the authentication process when joining the group.

Why Use Groups?

P2P networks have several key differences from traditional networks, the most
important being the ability to control what peers can do. The following are some
of the problems:

Too many peers connecting to one peer for a resource.

Peers that use resources but do not contribute to resources.

Certain resources should only be accessible to a set group of
individuals.

Hackers of the general network who are seeking to damage or take over the
network.

In P2P networks, it's very difficult to control behavior of rogue peers.
There are many different types of mischief, including abuse of other peer's
resources. There is also the obvious need to limit access to applications or
resources for security or privacy reasons.

To begin to understand how these problems can be overcome, let's look
at a use case diagram of a simplistic P2P system. In Figure
2.4, users interact with different instances of a service-A, which collaborates
with other services to access specific resources attached to specific instances.
In this sort of P2P network, the services are left with the responsibility of
security. Each service on each peer must act as a gatekeeper to the data controlled
by the peer.

Figure 2.4: Functional view of the peer service use case.

The drawing in Figure 2.5 is representative
of how JXTA works. In JXTA, the peer group is a virtual gatekeeper. The service,
and thus the service data, resides in the context of the group. The group code
is replicated on each platform, but we are showing it as a single entity accessed
by all of the group members. The services are accessed through the group, and
the services have a context of the group.

The key difference here is that the group contains the security features while
the services are only concerned with verifying that other peers are valid members.
Credentials created by the group and given to the peers (not shown) will be
validated by the group context. Figure 2.5
shows how groups are seen programmatically in JXTA. As can be seen, users interact
with a service controlled by the group. The group is ensuring a single point
of control, despite the fact that the service and data is distributed.

Figure 2.5: Conceptual view of group-based service.

By using groups, you have at least a chance of controlling peers with a
common authentication scheme. You also have a platform to disseminate
information to a limited set of group members. For example, you could send a
message to other peers that a rogue peer should be ignored.