JXTA in a Nutshell

Running the Example

To run both the RestoPeer and HungryPeer applications you must create two separate directories. Place the HungryPeer.java file in one directory, and the RestoPeer.java file in another directory. Each source file is compiled as we discussed in Chapter 3. The applications must exist in separate directories so that their configuration information will remain separate.

Let’s compile and start the HungryPeer first and see what happens:

piccolo% cd ch04/HungryPeer
piccolo% javac HungryPeer.java
piccolo% java HungryPeer

Security initialization in progress.
This will take 10 or more seconds ...

Attempting to discover the RestoNet Peergroup
Sorry could not find the RestoNet Peergroup

When you start the application, you’re first presented with the configurator. After filling it out, you’ll see the output listed above. The HungryPeer application attempts to discover the RestoNet peergroup and aborts after 3 tries (a total of 30 seconds). This is what we’d expect, since the RestoPeer application has not yet created the RestoNet peergroup.

Oddly enough, when you run this example you may find instead that the HungryPeer has jointed the RestoNet peergroup. There is no black magic here; this just means that someone else has already run the RestoPeer service on your JXTA network. Similarly, once the HungryPeer has found the RestoNet peergroup, it caches this information; if you rerun the HungryPeer at a later point, it will report that it has found the RestoNet peergroup even if no instances of the RestoPeer service are presently running on your network.

Let’s now compile and run the RestoPeer application:

piccolo% cd ch04/RestoPeer
piccolo% javac RestoPeer.java
piccolo% java RestoPeer
Attempting to Discover the RestoNet PeerGroup
Could not find the RestoNet peergroup; creating one
RestoNet Restaurant (Chez JXTA) is on-line
Waiting for HungryPeers

Again, the application first runs the configurator. Remember that if you are running both peers on the same host, you’ll need to use the Advanced panel of the configurator to change the ports of one of the peers (e.g., change the TCP port to 9703 and the HTTP port to 9702). After you complete the configurator, the program continues and prints the output listed above.

RestoPeer attempts first to find the RestoNet peergroup. After approximately nine seconds (three attempts at three seconds each to discover the advertisement), RestoNet stops searching. RestoPeer then creates a new RestoNet peergroup advertisement and joins the RestoNet peergroup as the first peer. As before, if another RestoPeer has run on your network, this service will discover and join the existing RestoNet peergroup.

Peer Cache Manager

After running the HungryPeer or RestoPeer, you may have noticed that a new directory (.jxta) was created under the current directory, which contains several other directories. The cm directory is the persistent cache for the platform; it contains advertisements that have been cached on the local peer. Here’s what the contents of .jxta might look like:

cm:
total 0
drwxr-xr-x    1 sdo      unknown         0 Jan  5 16:33 info-jxta-NetGroup
drwxr-xr-x    1 sdo      unknown         0 Jan  5 16:33 info-jxta-WorldGroup
drwxr-xr-x    1 sdo      unknown         0 Jan  5 16:34 info-uuid-
2FD9ECF01D3D4B5CB4A9B8A67B4CC51F02
drwxr-xr-x    1 sdo      unknown         0 Jan  5 16:33 jxta-NetGroup
drwxr-xr-x    1 sdo      unknown         0 Jan  5 16:33 jxta-WorldGroup
drwxr-xr-x    1 sdo      unknown         0 Jan  5 16:34 uuid-
2FD9ECF01D3D4B5CB4A9B8A67B4CC51F02

The cm directory contains an info- and a jxta- directory that correspond to each peergroup; in this case the uuid-2FD9ECF01D3D4B5CB4A9B8A67B4CC51F02 suffix corresponds to the RestoNet peergroup. You may want to look at the cm directory after running each example later in the book to see how the local cache of RestoPeers and HungryPeers is populated.

Advertisements are published with a time-to-live value that controls their lifetime; this value is specified by whoever first publishes the advertisement. When the advertisement expires, JXTA removes it from the cache.

Troubleshooting the cache

The presence of the cache has its advantages and disadvantages. It can greatly speed up discovery, since it contains all the information the application has previously discovered. On the other hand, there’s no guarantee that the advertisements in the cache are still valid; they may point to obsolete resources. This is integral to the notion of a P2P network; peers and their resources are known to be unreliable or transient.

There’s a balancing act going on here. You want to use the cache because it helps the performance of your application. At the same time, you don’t want to keep the cache forever, because over time many of the advertisements that it contains will become invalid. To help prevent many of the problems that can occur with stale advertisements, JXTA ages its advertisements. Still, you may periodically need to reset the cache, particularly when you’re testing new applications or have not run the application for some time. To reset the cache, delete the entire cm directory before restarting the platform.

Conversely, you can manually add advertisements to your cache in place of discovery; to do so, simply copy the file from an existing cache (one created by another application).

Rerunning the Applications

Let’s run RestoPeer again and see what happens. The RestoPeer now prints out these lines:

Attempting to Discover the RestoNet PeerGroup
Found the RestoNet Peergroup advertisement; joined existing group
RestoNet Restaurant (Chez JXTA) is on-line
Waiting for HungryPeers

RestoPeer tries to discover the RestoNet advertisement. It finds the advertisement right away and joins the RestoNet peergroup. The discovery is much faster since the RestoNet advertisement is now cached by the peer, and the RestoPeer only needs to perform a local discovery and join the peergroup.

With the RestoPeer still running, let’s again run the HungryPeer. We get this output:

Attempting to discover the RestoNet Peergroup
Found the RestoNet PeerGroup Advertisement
The HungryPeer joined the restoNet PeerGroup

The HungryPeer tries to discover the RestoNet advertisement. After a few seconds, the “Found the RestoNet” message prints out, indicating that the peer found the RestoNet advertisement. HungryPeer uses the advertisement to instantiate and join the RestoNet peergroup.

Now when we run HungryPeer again, it prints out this output:

Attempting to discover the RestoNet Peergroup
Found the RestoNet PeerGroup Advertisement
The HungryPeer joined the restoNet PeerGroup

The difference is that now the “Found the RestoNet” message appears right away. Because the advertisement was cached, no discovery request needed to be sent. The HungryPeer instantiates and joins the RestoNet peergroup as before. This illustrates the capability of the HungryPeer to learn information and make discovery work faster the second time around.