ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.

advertisement

AddThis Social Bookmark Button O'Reilly Book Excerpts: JXTA in a Nutshell

Getting Started with JXTA, Part 3

Related Reading

JXTA in a Nutshell
By Scott Oaks, Bernard Traversat, Li Gong

by Scott Oaks, Bernard Traversat and Li Gong

In part three in this excerpt from JXTA in a Nutshell, learn how to configure a JXTA application.

JXTA Application Configuration

The dialog box that we showed in Figure 2-1 (in part one of this book excerpt) should make a little more sense now. That box is called the JXTA configurator tool, and it's a basic feature of the JXTA platform. All JXTA applications use this tool when they are first configured.

Configuration information is stored by this tool in the local directory. The configuration information also includes a local port number on which the JXTA application will listen. For that reason, you cannot run two instances of the shell (or any other application) on the same machine from the same directory. Instead, you must do the following:

  • Create a new directory in which to hold the configuration information (e.g., /files/JXTA_Demo/Shell.2).

  • Copy the shell.sh or shell.bat script into that directory.

  • cd to that directory.

  • Execute the startup script.

When this shell starts, you will again be presented with the configuration box from Figure 2-1. You'll need to perform some advanced configuration in order for this second shell to run.

The configurator has four panels:

  1. Basic: The basic panel of the configurator allows you to assign a name to your peer. Any string can be entered (we chose "Test Shell 1"): it can represent a person's name, a hostname, or any other identifier. The name you enter is not guaranteed to be unique. No centralized naming service is used by the configurator; therefore, two peers may end up with the same name. This is okay, since the peer name is intended to be used only as a hint for searching or identifying peers. Also, each peer is assigned a peer ID that is guaranteed to be unique for every peer in the JXTA network.

    This panel also allows you to specify whether your machine is behind a firewall. If you are behind a firewall, select the option to use a proxy server and enter the proxy server's name and port into the given boxes. When a proxy server is enabled, requests to the rendezvous peers will be wrapped into HTTP messages before they are sent to the peer.

  2. Advanced: The advanced panel allows you to set up network information about the peer. JXTA v1.0 supports two transports: TCP/IP and HTTP. By default, the configurator tool preconfigures both a TCP/IP and HTTP transport to communicate with other peers.

    In This Series

    Getting Started with JXTA, Part 5
    In this fifth and final excerpt on getting started with JXTA from JXTA in a Nutshell, learn about advertisements: structured XML documents for JXTA infrastructure.

    Getting Started with JXTA, Part 4
    In part four in this series of book excerpts from JXTA in a Nutshell, learn about JXTA pipes.

    Getting Started with JXTA, Part 2
    In part two of this series of book excerpts on getting started with JXTA, from JXTA in a Nutshell, learn about peergroups and discovery, which are important for understanding peer-to-peer Web services.

    Getting Started with JXTA, Part 1
    In part one in this series of excerpts from JXTA in a Nutshell, learn about setting up the JXTA Java environment as well as JXTA class files, shells, and peers.

    You should enable the TCP settings if there are other JXTA peers on your local network that you want to discover through the broadcast mechanism of PDP. The choice menu lists all the networks that the machine knows about; these are the networks on which the shell could listen for broadcast messages from other peers. Note, however, that you can select only one network on which to listen for messages.

    The text box in the TCP/IP configuration section contains the network port that will be used for application-level messages to other peers. If you are running multiple instances of the JXTA platform on a single computer, you must change the port number parameter: each JXTA application needs to have its own port number to bind a listening socket to the port.

    Similarly, enable the HTTP settings if you want to make connections to the rendezvous hosts we listed above. Note that you enable this to use HTTP to rendezvous to those hosts regardless of whether you're behind a firewall or use Network Address Translation (NAT). The message here is a little misleading. If you're behind a firewall, then you should enable the proxy server on the basic panel and fill in its name and port number as appropriate. Making connections through the HTTP rendezvous ports can take some time; while you're experimenting with JXTA on your local network, it's more efficient to disable this feature (though you'll lose the ability to interact with other peers on the Internet while this feature is disabled). If you are not connected to the Internet, you must disable the HTTP settings.

    One more note about the TCP port. Peers on a local TCP network discover each other through a multicast message. However, once they've discovered each other, they communicate directly over a specific port (known as the endpoint). The value of the endpoint is embedded within the PDP messages that the peers exchange. A peer listens for connections on this port; one peer contacts another by making a connection to the second peer's endpoint. That's why we had to change the port number when we started a second shell on the same machine: each shell needs an unused port number on the machine. If you run two shells on different machines, changing the port isn't necessary.

  3. Rendezvous/relays: The rendezvous/relays panel allows you to specify specific hosts to be used as rendezvous and/or relay peers. By default, JXTA peers will download the lists of HTTP rendezvous peers by connecting to http://rdv.jxtahosts.net/cgi-bin/httpRdvsProd.cgi and HTTP relay peers by connecting to http://rdv.jxtahosts.net/cgi-bin/routersProd.cgi. If you press the Download relay and rendezvous lists button at the bottom of this panel, you can specify a different location from which to load these lists. When the lists are loaded, you'll see that the default addresses for JXTA.ORG 235 and 237 have been added as both rendezvous and relay peers. You may delete either of these peers or add any other peers through the fields on this panel.

    Note that if you disabled the HTTP transport on the advanced panel that the HTTP rendezvous and relay settings are not available.

  4. Security: The final panel is one we've seen: it requires you to enter a name and password for access to this peer. Whenever the peer is restarted from this directory, you will be prompted for the values you entered into this panel.

Re-Entering Configuration Information

Network configuration information that you enter in the configurator is stored in the PlatformConfig file of the current directory. When a JXTA application starts, it consults this file to determine how it should configure itself. Information about your username and password is stored in files within the ./pse directory.

The first time that you start an application in a directory, the configurator will run and automatically create those files. After that, if you need to change the configuration information, you must remove the PlatformConfig file (to change the network information) and/or the pse directory (to change the username and password). Alternately, you can create a file called reconf in the current directory, in which case the configurator will run, and you'll be allowed to change the network information (but not the username and password).

From the shell, you can create the reconf file with the peerconfig command:

JXTA>peerconfig
peerconfig: Please exit restart the jxta shell to reconfigure !!!!!

Then exit the shell and restart it; the configurator will reappear, and you can enter new network information.

Pages: 1, 2

Next Pagearrow