March 4, 2021
Hot Topics:

Overview of JXTA

  • By Sams Publishing
  • Send Email »
  • More Articles »

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.


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.

Page 3 of 6

This article was originally published on August 21, 2002

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date