Peer to peer programs are gaining more popularity on the internet and in the enterprise. This gives an overview of what P2P is and how JXTA can be used to write P2P applications

What is P2P?

What exactly is peer-to-peer (P2P) computing?  What differentiates it from other computing paradigms?  You could say that when computers were first networked together they formed a P2P network.  Email servers, DNS servers, video games, and voice-over-IP have all been dubbed “P2P” systems at some point in time. Recently, applications such as Kazaa, Gnutella and Napster have been the popular programs that many think about when they hear “P2P”.  You can see the issue at hand; P2P doesn’t really have a simple, concise definition.  In trying to define “P2P”, we should look at the key concepts and not the literal protocols or implementations.

P2P is not a single technology or implementation and cannot be easily characterized by one factor.  Many have tried to characterize P2P applications based on the degree of centralization, but this is a dramatic oversimplification that cuts through the basis of P2P computing.  In general, P2P is a computing paradigm that makes networks symmetrical; there may be centralized services but the client (or peer) is the overall focus of the application or implementation.  Centralized P2P applications often use a central catalog to store references to information, but employ peer functionality to transfer or communicate that information.  Decentralized P2P applications are often simple, cloned peers with no differentiating characteristics except for the content being distributed and shared.  Of course, there are several applications/foundations that mix these two types together, which is mostly why one should not look to centralization as a sole means of classification (JXTA, Seti@Home).  If we look at our earlier examples, we see that both Napster and Gnutella do fall within the general bounds of P2P, but we also see that Gnutella has more of a “peer-centric” structure, while Napster employs a “centralized” structure.  The difference here is that Napster clients can do little without the centralized server and the Gnutella clients will maintain nearly all functionality when a peer is added and/or removed.  In both of these applications, however, the client-server model is broken and data is distributed amongst a broad array of peers.   Shortly, we will find that JXTA mixes these two “styles”, hoping to find a stable, scaleable, middle-ground.

The concept of P2P has been around for quite some time and finally the proliferation of connected devices, increase of bandwidth speeds, increases in computing power and larger storage capacities are leading P2P to the forefront in next-generation application development.  How might one maximize the practicality of an application that utilizes most of the advancements listed above?  One good option is by implementing an application built around the JXTA foundation protocols.

What is JXTA?

In an effort to ease the development of P2P networking applications, Sun Microsystems created JXTA.  JXTA is a set of protocols that are layered on top of proven network protocols such as TCP and HTTP. These protocols are defined in terms of XML messages.  Also, JXTA does not require a specific operating system or programming language; instead JXTA relies on its set of protocol specifications for the foundation of a P2P application.  There are several key concepts that one should understand when developing a JXTA application.  These concepts, when mated with the standard protocols, allow for a high-level understanding of JXTA and its capabilities as a P2P foundation.

Key JXTA Concepts:

Peers

A Peer is any networked device that implements one or more of the JXTA protocols. Peers can include phones and PDAs, as well as PCs or servers. It is assumed that all peers operate asynchronously and independently from each other.  Each peer is uniquely identified by a Peer ID.  Peers may exist in many different forms with different functions.  One specific example is an intermediary peer, which is used to route messages to peers separated by their network configuration (e.g., NATS, firewalls, Proxies).

Peer Groups

A Peer Group is a collection of peers that have agreed upon a common set of services.  Another way to look at this is that all peers in a group have a common interest. Peers may belong to more than one peer group at any given time. By default, the first group that is instantiated is the Net Peer Group: all peers belong to the Net Peer Group. Peers may elect to join additional peer groups.  As with the peer, each peer group is defined by its own unique PeerGroup ID. Peer groups may be used in a variety of ways: they may be used to create secure groups, limit available scope, or implement monitoring of peers.  The JXTA protocols describe how peers may publish, discover, join, and monitor peer groups.

Advertisements

Advertisements in JXTA are similar to advertisements in the real world; JXTA uses advertisements to describe resources.  In JXTA these advertisements usually define a specific group of resources, i.e. Peers, Peer Groups and Modules.  Advertisements are central to the development of a successful P2P application.

Pipes

Pipes are communication channels that connect services and applications.  Pipes are the main transport for messages that flow through a JXTA application.  There are several types of pipes, but the standard pipe is both asynchronous and uni-directional.  This type of pipe is lightweight but it also does not make any guarantees as to security and completeness of your data.  There are other pipes that one might implement, but as with all applications, tradeoffs must be closely scrutinized on a case-by-case basis.  Connecting the various pipes to endpoints or other pipes is left up to the Pipe Binding Protocol, which is discussed in the next section.

Services

Services in JXTA represent any kind of service available on a network.  Yes, it is that broad.  Services may include web services, RMI services, CORBA services; the list goes on.  JXTA mainly uses pipes to invoke services, but this is not a requirement as JXTA can use other standards such as WSDL and SOAP to invoke services as well.   

There are two main types of services: one that applies to peers and one that applies to groups.  Peer services are services associated with a specific peer. Peergroup services, on the other hand, are associated with the peergroup and you will usually find instances on all peers within a group.  The latter type of service allows for high availability, for as long as one member of the group is alive, the service will be available. 

The JXTA 2.1.1 specification includes the following protocols:

Peer Discovery Protocol – This protocol is used by peers to advertise their own resources (e.g., peers, groups, pipes, or services) and discover resources from other peers.

Peer Information Protocol – This protocol is used by peers to obtain status information (uptime, state, traffic, etc.) from other peers.

Peer Resolver Protocol – This protocol enables peers to send a generic query to one or more peers and receive a response to the query.

Pipe Binding Protocol – This protocol is used by peers to establish a virtual communication channel between one or more peers.

Peer Endpoint Routing Protocol – This protocol is used by peers to find routes to destination ports on other peers. Route information includes an ordered sequence of relay peer IDs that can be used to send a message to the destination. (For example, the message can be delivered by sending it to peer A, which relays it to peer B, which relays it to the final destination.)

Rendezvous Protocol – This protocol is used by peers to propagate messages within a peer group.

A JXTA Peers may utilize all of these protocols, or it may utilize only one, depending on the need of the peer in a given application.

Sample JXTA Application Architecture for Firewall/NAT traversal

We will outline a JXTA application running on five clients.  We will focus on communications with Peer2 and examine the methods employed by the other peers in the network space. In the following diagram you can see Peer1 and Peer3 will access Peer2 via TCP because there is no restriction on TCP traffic on their network. Peer4 and Peer5 happen to be in the same peer group, but there is a firewall blocking TCP traffic to Peer2. In this case, we need another peer to act as a relay between the restricted nodes.  Using standard JXTA protocols, we set up a JXTA relay running on port 80 on the Internet. In order to ensure communication between the protected nodes, we configure our JXTA applications to use the http relay and http rendezvous of our JXTA relay. With this configuration, JXTA will first attempt to communicate via TCP and if it fails, it will attempt to communicate via HTTP with the given Relay/Rendezvous. The Rendezvous acts as a messenger for the peers. If Peer4 opened a pipe to Peer2 the messages would be sent to the Rendezvous and Peer2 would get the message from the Rendezvous on behalf of Peer4. JXTA uses Jetty for their HTTP server, which is a popular and stable open-source product.

The code we used for the relay was as follows: 

public class Relay implements Runnable {

     private PeerGroup group;

    private RendezVousService rdvService;

    private DiscoveryService discovery;

    public static void main(String args[]) throws Exception {

        Relay app = new Relay();

        app.startJxta();

        app.run();

    } 

    private void startJxta() throws Exception {

        try {

            // create, and Start the default jxta NetPeerGroup

            group = PeerGroupFactory.newNetPeerGroup();

        } catch (PeerGroupException e) {

            // could not instanciate the group, print the stack and exit

            System.out.println("fatal error :NetPeerGroup group creation failure");

            e.printStackTrace();

            System.exit(-1);

        }

        discovery = group.getDiscoveryService();

        RendezVousService rdvServicee = group.getRendezVousService();

        rdvServicee.startRendezVous();

    } 

    public void run() {

        System.out.println("Router/Rendezvous Peer Started..n");

        while (true) {

            try {

                Thread.sleep(60000);

            } catch (InterruptedException ie) {

                System.exit(0);

           }

        } 

    }

}

Only registered users can write comments.
Please login or register.

Powered by AkoComment 1.0 beta 2!