- Protocol and API
- JXTA Goals
- JXTA Peer and Java
- Overview of the JXTA Protocols JAVA API
- Summary of Java API for JXTA Protocols
- Where JXTA Applications Begin
- The Peer
- Starting JXTA
- Peer Discovery Protocol API
- Peer Resolver Protocol API
- Peer Information Protocol
- Peer Membership Protocol
- Pipe Binding Protocol API
- Peer Endpoint Protocol
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
JXTA Peer and Java
A peer is a node in the JXTA network. Each peer belongs to one or more groups and implements a set of services that allows other peers to interact with this peer, or to others of which the peer is aware. For most of the initial applications written, the peer is synonymous with the user, even though this is not ideal. Identity is left up to the implementer of the application. The peer is best thought of as a computer that does not care about identity. Keep this in mind when you write a JXTA application, and be sure to add some form of user identity.
A JXTA peer in the Java implementation is associated with one JVM. Having only one peer per device, such as a PC, is the normal scenario. You can start multiple JVMs to create multiple peers on a PC, but this is only really worth doing for debugging and experimentation. If you want to start multiple copies of JXTA applications, you need to do so in separate directories and use different communication ports to avoid the applications from conflicting. The key reason to use a separate directory is because of the cache management system.
The cm Directory
The cache management system is used to store information about the peer-to-peer (P2P) network. This information is primarily advertisements created by the peer or found on the network during discovery. The advertisements are stored as files with filenames that use the ID of the advertisement. Note that this is just the first version of the cache manager, and future versions may use a database instead of files.
The reason for such persistence is obvious when you consider there are hundreds of peers to interact with. Without local caching, you would need to contact a good portion of these peers to rebuild information required for your application.
The cache is required because it is very costly to accumulate advertisements. For example, to get a peer advertisement of a peer you would like to chat with, you may need to pass through several rendezvous peers just to locate the peer. If you had to perform this operation every time, you would significantly reduce the performance of your application over time. The network would also be clogged with discovery messages from peers constantly rediscovering the information each time they started.
Each JVM instance has one associated peer because information is stored in the directory from which JXTA is launched. There are files in this rooted directory, along with various other directories and files.
One root directory created when the peer is started for the first time is the cm (cache management) directory. The content that is being managed are the advertisements that are both created locally and fetched from the P2P network. The role of the cm directory is to act as a local cache of these advertisements. The cache acts as a form of persistence between sessions. Without the cache, the advertisements would have to be reloaded from other peers.
Below the cm directory are group directories. For each group you join, there is a corresponding directory. There are two directories , which are always created because all peers belong to the World and Net groups. These directories are named jxta-NetGroup and jxta-WorldGroup for the Net and World groups, respectively.
As the peer joins new groups, new directories are added. Using the group ID, JXTA creates the directories. Each group directory contains information about advertisements discovered in the group and any other information about the group, such as membership and credentials.
Note
You can use the cm directory for monitoring the health of your peer and for debugging. If you are having problems with your messaging, the cm directory is very useful for debugging.
Looking at files in the group directories can help show that your application is connecting to the JXTA network. As you do remote discovery, peer and other advertisements will get written to these directories. Without writing code, you can examine the XML and learn about what is happening.
Another directory that can exist in the cm directory is the HttpTransport directory. This directory exists only if your peer is an HTTP gateway. The directory is used to manage messages from other peers that are using this peer as a middleman. Remember, from Chapter 2, that peers behind a firewall need a gateway that stores incoming messages.
Additional directories can also show under cm or other subdirectories (tmp, public, and private show up under group directories, but are not used). In future versions of JXTA, a database could be used instead of the file system. For now, using the file system is adequate for many applications.
PSE Directory
Another directory that appears where you run your peer is pse. The directory contains certificates, password files, and other information related to peer security.
Be careful not to modify any of these files. You can delete the pse directory if you want to start your peer security from scratch, but be careful about doing this. In the future, this directory may contain other data for the application that should not be deleted.
When the peer configuration tool cannot find the pse directory, it creates it. The system then asks for your login and password to create the appropriate files and initialize the security system.
The current implementation uses the pse information for secure pipes. In addition to pipes, there are additional uses for this information, such as logging into groups and signing messages.