Overview of JXTA
Pipe Binding Protocol
The Pipe Binding Protocol is used to create virtual channels between peers. The protocol uses the Endpoint Protocol that it abstracts to allow pipes to be created that use supported transport protocols, such as the JXTA HTTP Transport, the JXTA TCP/IP Transport, or the secure JXTA TLS Transport.
To use a pipe, an advertisement must be published and then used by other peers. When a peer has a pipe advertisement, the peer makes a pipe bind request, which is responded to by a peer accepting the pipe.
MsgTypeDefines this message as a query an answer. For the query, it will be Query.
PipeIdPipe ID being resolved.
TypeThe type of pipe resolution requested.
CachedFalse if the answer can not come from the cache.
PeerA peer ID of the only peer that is to answer that request. This tag is not required because, in many instances, you do not explicitly connect to a specific peer.
The reply to a pipe bind uses the same schema, but there are additional tags and a slightly different interpretation applied to their contents. With the data from both messages, the Pipe Binding Protocol can use the Endpoint Protocol to create a route between peers and select the appropriate protocol based on the peers involved. The following is the reply message that contains the other peer that can then be used to locate the other peer's endpoint:
MsgTypeDefines this message as a query an answer. For the answer, it will be Answer.
PipeIdThe Pipe ID being resolved.
TypeThe type of pipe resolution requested.
FoundResponse value showing success or failure that an Input Pipe was found on the specified peer.
PeerAdvPeer Advertisement of the peer that connects to the Input Pipe.
The following is the XML schema for the pipe-binding message:
<xs:element name="PipeResolver" type="jxta:PipeResolver"/> <xs:complexType name="PipeResolver"> <!-- should be an enumeration choice --> <xs:element name="MsgType" type="xs:string"/> <xs:element name="PipeId" type="xs:anyURI"/> <xs:element name="Type" type="xs:string"/> <!-- used in the query --> <xs:element name="Cached" type="xs:boolean" default="true" minOccurs="0"/> <xs:element name="Peer" type="xs:anyURI" minOccurs="0"/> <!-- used in the answer --> <xs:element name="Found" type="xs:boolean" minOccurs="0"/> <!--This should refer to a peer adv, but is instead a whole doc--> <xs:element name="PeerAdv" type="xs:string" minOccurs="0"/> </xs:complexType>
The resolver is used to send queries throughout the P2P network. The resolver is used by base services, such as the discovery mechanism to search for advertisements. You can also use the resolver when you have a query response model of communication where answers come from a group of peers rather than a specific peer.
The following is the XML schema for the ResolverQuery message:
<xs:element name="ResolverQuery" type="jxta:ResolverQuery"/> <xs:complexType name="ResolverQuery"> <xs:element name="Credential" type="xs:anyType" minOccurs="0"/> <xs:element name="SrcPeerID" type="xs:anyURI"/> <!-- This could be extended with a pattern restriction --> <xs:element name="HandlerName" type="xs:string"/> <xs:element name="QueryID" type="xs:string"/> <xs:element name="Query" type="xs:anyType"/> </xs:complexType>
The following is an explanation of the tags:
CredentialThis is the credential of the peer sending the query.
HandlerNameThe name associated with a resolver handler that listens for messages of this type.
QueryID An ID that is used to link to the response. This ID is important because the order of responses to queries is not guaranteed. It is also used in case there are duplicate responses to the query, which is also possible.
QueryThis is where you put application data for the other peers to examine. If you plan on an XML message, the message must be escaped.
The following is the XML schema for a ResolverResponse message:
<xs:element name="ResolverResponse" type="ResolverResponse"/> <xs:complexType name="ResolverResponse"> <xs:element name="Credential" type="xs:anyType" minOccurs="0"/> <xs:element name="HandlerName" type="xs:string"/> <xs:element name="QueryID" type="xs:string"/> <xs:element name="Response" type="xs:anyType"/> </xs:complexType>
What follows is an explanation of the tags for the resolver response message:
CredentialThis is the credential of the peer sending the response.
HandlerNameThe name associated with a resolver handler that listens for messages of this type.
QueryIDAn ID that is used to link to the query. This ID is important because the order of responses to queries is not guaranteed. It is also used in case there are duplicate responses to the query, which is also possible.
ResponseThis is where you put application data for the other peers to examine. If you plan on an XML message, the message must be escaped.
The Rendezvous Protocol describes how messages are propagated peers in the member group. The Rendezvous Protocol uses the Peer Endpoint Protocol to locate the peers in the group and determine routes and transports. The Peer Resolver Protocol uses the Rendezvous Protocol to send messages, so you should not access the Rendezvous Protocol or its implementation directly.
Even though the Resolver Protocol should be used instead of the rendezvous, it is important to understand the messaging that occurs to get an idea of how messages flow in the system.
Rendezvous Advertisement (RdvAdvertisement)
The Rendezvous Advertisement (RdvAdvertisement) is very simple and only has the following three tags:
NameName of the rendezvous peer
RdvPeerIdPeer ID of the rendezvous peer
The connection between a peer and a rendezvous peer is achieved by a connection, associated with a lease. A lease is a concept that basically means that the connection is promised for a certain period of time. The lease must be requested before the connection is allowed. When the lease is granted by the rendezvous, the peer can begin using the connection until the lease expires or the lease is canceled by the peer or the rendezvous. The length of the lease is determined by the rendezvous and is not guaranteed to expire normally. When a peer is done with the connection, it can send a cancel request, which, if granted, the rendezvous will reply with a lease canceled message.A set of queries and responses are defined by the Rendezvous Protocol to establish connections:
LeaseRequestMessage a peer uses to request a connection to a rendezvous. A rendezvous that grants a connection lease returns the LeaseGranted message.
LeaseGrantedMessage sent by a rendezvous to indicate the lease has been granted.
LeaseCancelRequestMessage is sent by a client to its rendezvous to cancel an existing lease. The rendezvous should reply with LeaseCancelled, but this is not guaranteed.
Determining three qualities about each message received controls propagation. First is its time to live (TTL) parameter. If the message has expired, the message is ignored. Second is the loop; if the message has been seen before, it is discarded. Third is the duplicate that tests to see if the message has been processed.
The reason for loop and duplicate tests is that a looped message is a message that has already been ignored or processed while the duplicate test checks to see if it was processed. A message may be handled differently if it is looped but not yet processed. This is because the rendezvous may discard a message, process it, or be interested but not at this instant. A message must be alive, not processed and not looped, before it can be processed completely. It may be optionally processed if it is still alive, has looped, but not processed.
Remember that a propagated message may be seen several times by the rendezvous. By using the path, the TTL, and the ID of the message, the rendezvous can avoid forwarding messages to peers that have already seen the message or that the rendezvous has already processed itself.
This control is accomplished by adding a RendezVousPropagateMessage message element within each propagated message. The XML schema for the element is as follows:
<xs:element name="RendezVousPropagateMessage" type="jxta:RendezVousPropagateMessage"/> <xs:complexType name="RendezVousPropagateMessage"> <xs:element name="MessageId" type="xs:string"/> <!-- This should be a constrained subtype --> <xs:element name="DestSName" type="xs:string"/> <xs:element name="DestSParam" type="xs:string"/> <xs:element name="TTL" type="xs:unsignedInt"/> <xs:element name="Path" type="xs:anyURI" maxOccurs="unbounded"/> </xs:complexType>
The RendezVousPropagateMessage holds the information used by the rendezvous to determine specific information about the message and its routing.
JXTA has many identifiers. We have shown most of them earlier in the chapter as parts of the advertisements. They are used for identification, indexing, and searching. There are usually two specific identifiers in most advertisements. The first is the advertisement ID. This ID is generated when the advertisement is created. One way to look at the advertisement identifier is that it is like an object reference. The identifier has no real value other than to give each advertisement a unique number. The second identifier is one associated with the advertisement type.
The format of identifiers vary according to their intent and use. Identifiers vary from simple names to unique identifiers that can consist of rather long sequences of numbers and letters (please refer to the earlier section titled "Modules" for examples of the different identifiers).
Codat is an invented word that is short for "code and data." In the documentation of the Codat class, we find the following definition:
The JXTA platform defines Codat as the unit of information shared and exchanged within a JXTA group. All instances of Codats reside within a peer group. The PeerGroup content caching service provides storage and retrieval methods for codats using codatId as index.
A codat, therefore, represents data and can contain code or a reference to code. In a group advertisement, the code is defined by the service definitions in the parms tag. These service advertisements have unique names that reference code implementations.
A Codat ID is defined in the JXTA spec as follows:
Codat IDs refer to codats. A Codat ID should canonically, uniquely and unambiguously refer to a codat. ID Formats may OPTIONALLY support this ID Type. If a JXTA binding recognizes the ID Format, it should be able to extract a Peer Group ID from a Codat ID. This Peer Group ID identifies the peer group to which the codat belongs.
In the definition, canonical simply means unique. To say it more precisely, there is no more than one ID or official name for the same resource. On the Web, an HTTP URL is a canonical name for a Web page.
The peer ID is a reference to a specific peer. The peer ID is valid for the time that the peer exists. Because peers are persistent, the peer ID is reused each time the JXTA peer is started. The only time the peer ID is destroyed is when you delete the configuration manually or uninstall the peer platform. The next time the peer is started, a new peer ID will be created.
Peer group IDs are used to locate and index groups. The lifetime of a group ID is variable. Public groups do not change. Groups that are temporary should have an expiration associated with them. It is up to the group creator to define the lifetime of the group.
The service ID is used to define a codat. The ID is associated with a unique piece of code.
The pipe ID is used to advertise a communications channel within a group or service. The pipe is often only valid for the running time of an application. In at least the initial versions of JXTA, the pipe ID has a very good chance of being invalid. It is possible to reuse a pipe ID, but this is not of much use. The pipe ID also contains the ID of its parent group to help with indexing and verification of the group context.
This chapter has covered the top layer of the JXTA protocols. You should at least have a grasp of how JXTA works and its key systems. You should now also understand P2P networking and P2P applications a little better.
We have not gone too deeply into the protocol because this should be all you need to begin understanding how JXTA works. Remember, the JXTA protocol is really just a set of messages. So far, we are just brushing the surface of JXTA. The protocol is relatively useless without a platform that implements it. You also need to know how we can take advantage of the protocol.
About the AuthorDaniel Brookshier is a world-class Java consultant, author, and speaker with 20 years of experience. Mr. Brookshier's knowledge of software development covers many industries, including transportation, telecom, wireless, healthcare, B2B, petroleum engineering, law, insurance, software tools, and aerospace. He is an international consultant with contract assignments in the United States, Norway, the United Kingdom, and China. Mr. Brookshier is the founder of two Java user groups in Dallas, Texas, the writer of several Java programming books, and he has published numerous articles about Java in industry magazines. Daniel is a recognized expert on Java software development, Java standards, Java Management, enterprise software, and JavaBeans component development. Daniel can be reached at email@example.com
JXTA: Java P2P Programming 0-672-32366-4 by Daniel Brookshier, Darren Govoni, Navaneeth Krishnan, and Juan Carlos Soto
Source of this material
|This material is from Chapter 2, Overview of JXTA, from the book JXTA: Java P2P Programming (ISBN: 0-672-32366-4) written by Daniel Brookshier, Darren Govoni, Navaneeth Krishnan, and Juan Carlos Soto, published by Sams Publishing. .|
To access the full Table of Contents for the book
Page 6 of 6