Getting Started with JXTA, Part 3
Pages: 1, 2
Firewall and NAT Traversal
A fundamental problem P2P systems such as JXTA need to address is the ability to create a connection between two peers located at the edges of the Internet. Firewalls and NAT solutions currently deployed on the Internet create logical partitioned zones that preclude peers from talking directly with each other.
Firewall solutions are primarily deployed to create protected regions and to limit incoming traffic from the outside world. Many companies on the Internet today use firewall software to protect their internal networks from unwanted external intruders and traffic; home firewalls are becoming increasingly popular for individual users as well.
NAT solutions address the limitation on the number of IP addresses that can be assigned on a particular local network. These limitations stem from two areas. First, the sheer number of devices that are connected to the Internet is greater than the present address space of IP addresses. Second, many users (particularly home users with small networks) prefer to use NAT to shield information about their network topology from the outside world and to limit the number of IP addresses they must purchase from their service provider. IPv6 will eventually solve the first of these issues, but not the second.
So both firewalls and NAT address real problems; they will be a reality of public networks for the foreseeable future. P2P networks such as JXTA need to provide traversal and piercing capabilities to enable any peer on the network to talk with any other peer. JXTA assumes uniform reachability between peers, independently of their physical location in the network (e.g., behind a firewall or NAT).
Therefore, JXTA implementations must support firewall traversal and NAT piercing. This is accomplished in JXTA 1.0 using HTTP; it's important to set the fields of the configurator correctly to take advantage of these features.
Command Line-Based Configuration
In certain environments, it may not be convenient to configure the JXTA platform via a graphical interface. In that case, you must configure the environment by hand. There are two issues here: the network configuration and the security configuration.
The network configuration information is stored within the PlatformConfig file located in the current directory. If you want to change network parameters, you can edit this file by hand before starting your JXTA application. If you are running a brand new JXTA application, you can copy an existing PlatformConfig file, make any necessary changes to it, and then run your application. Alternately, if no windowing system is available when the JXTA application starts, it will prompt you as to whether it should continue:
The window-based configurator does not seem to be usable. Do you want to stop and edit the current configuration ? [no]: Using the current configuration.
If you answer this question with anything other than the string "yes," JXTA will create a default PlatformConfig file and run with the network parameters set in that file. If you do answer "yes," the application will throw an exception and exit, allowing you to edit the PlatformConfig file.
You must configure the username and password differently. The username and password information is stored within the pse directory. If that directory does not exist, then the platform will always attempt to run the configurator. If the configurator cannot run, you will get the same prompt as above, but there is no default username or password, and the application will ultimately fail.
What you must do in this case is specify the desired username and password on the command line by setting these two properties:
Note that the password must be specified in "the clear"; it will not echo as a series of asterisks. Using these properties will initialize the correct entries in the pse directory and allow your application to continue.
The username and password must be specified every time a JXTA application runs; the second time you run the shell, you'll get a pop-up window asking you to specify the username and password. To avoid this pop-up window, you may specify these properties when you start the application.
There's an interesting difference here: if the application prompts you for the username and password, you will not be able to proceed unless you type in the correct values. If you specify the username and password via command-line properties, the application will continue to function until those values are needed. In most JXTA applications, the username and password are needed only to create secure (encrypted) pipes. Therefore, unless your application uses secure pipes, it will work perfectly even if you specify the incorrect username and password via the command line. We'll explore this a little bit further in Chapter 7.
The JXTA Shell caches information about peers it has discovered in the ./cm directory. If you shut down a shell and then restart it, you'll notice that it still knows about the same peers, even before you execute a
peers -r command. This caching feature is used by many JXTA applications, though it is not a requirement of JXTA: it's up to the application to determine how (or if) it should cache information about previously discovered peers.
So when the JXTA Shell restarts, it still knows about all of the previously discovered peers. But what happens if these peers have disconnected? In that case, you need to flush the list of peers. This is done with the
peers -f command:
JXTA>peers peer0: name = Test Shell 1 peer1: name = Test Shell 2 JXTA>peers -f JXTA>peers peer0: name = Test Shell 1
The point is that peers are strictly transient by nature, and you cannot assume that a peer will continue to exist if you restart a session (or even during the same session). Peers come, peers go, and it's up to JXTA applications to be prepared to deal with this fact.
The caching of peer information by the shell is a specific case of advertisement caching. Every network resource in JXTA is described by an advertisement. Advertisements are XML documents that publish the availability of a resource and specify how to access the resource (we'll discuss them in more detail later in this chapter). When we discovered a peer, what we really discovered was the advertisement for that peer.
Advertisements may be cached by peers. Caching advertisements facilitates advertisement discovery, as more peers are likely to cache the requested advertisement. Without caching, peers would have to crawl through the entire network to find the advertisement they are looking for. Thus, caching reduces the exponential growth of messages sent within the network to discover a resource.
Each advertisement contains a time-to-live value that specifies the lifetime of the advertisement in the JXTA network. The lifetime is specified as a time relative to when the advertisement was published; when the lifetime expires, the advertisement is purged from the cache. This enables the network to maintain itself without centralized control.
As we mentioned, the JXTA specification does not specify how peers cache information; each peer is free to use a caching policy appropriate for its own environment. A PDA may cache very few advertisements only for its own usage. An enterprise server may cache more advertisements and supply them to other peers in the network. However, the standard JXTA API bindings that we discuss in later chapters automatically perform this caching. So by default, most JXTA applications will cache their advertisements.
In the next installment, learn about Pipes.
Scott Oaks is a Java Technologist at Sun Microsystems, where he has worked since 1987. While at Sun, he has specialized in many disparate technologies, from the SunOS kernel to network programming and RPCs.
Bernard Traversat is a well-known developer in the Java Community and an active member of the Project JXTA. Bernard is the Engineering Manager for the JXTA CORE.
Li Gong is a well-known developer in the Java Community and an active member of the Project JXTA. Li is the JXTA Engineering Director for the JXTA CORE.
Return to ONJava.com.