The Pipe Binding Protocol
This chapter is from the book
This chapter is from the book
This chapter is from the book
Pipes are constructs within JXTA that send data to or receive data from a remote peer. Services typically use either a Resolver handler (refer to Chapter 5, "The Peer Resolver Protocol") or a pipe to communicate with another peer. Before a pipe can actually be used, it must be bound to a peer endpoint. Binding a pipe to an endpoint allows the peers to create either an input pipe for receiving data or an output pipe for sending data. The process of binding a pipe to an endpoint is defined by the Pipe Binding Protocol (PBP).
This chapter explains the Pipe Binding Protocol that JXTA peers use to bind a pipe to an endpoint. The PBP defines a set of messages that a peer can use to query remote peers to find an appropriate endpoint for a given Pipe Advertisement and respond to binding queries from other peers. After a pipe has been bound to an endpoint, a peer can use it to send or receive messages. Several examples in the section "The Pipe Service" demonstrate the use of both input and output pipes to send and receive data, respectively.
Introducing the Pipe Binding Protocol
The endpoint is the bottom-most element in the network transport abstraction defined by JXTA. Endpoints are encapsulations of the native network interfaces provided by a peer. These network interfaces typically provide access to low-level transport protocols such as TCP or UDP, although some can provide access to higher-level transport protocols such as HTTP. Endpoints are responsible for producing, sending, receiving, and consuming messages sent across the network. Other services in JXTA build on endpoints either directly or indirectly to provide network connectivity. The Resolver service, for example, builds directly on endpoints, whereas the Discovery service builds on endpoints indirectly via the Resolver service.
In addition to the Resolver service, JXTA offers another mechanism by which services can access a network transport without interacting directly with the endpoint abstraction: pipes. Pipes are an abstraction in JXTA that describe a connection between a sending endpoint and one or more receiving endpoints. A pipe is a convenience method layered on top of the endpoint abstraction. Although pipes might appear to provide access to a network transport, implementations of the endpoint abstraction are responsible for the actual task of sending and receiving data over the network.
To provide an abstraction that can encompass the simplest networking technology, JXTA specifies pipes as unidirectional, meaning that data travels in only one direction. Pipes are also asynchronous, meaning that data can be sent or received at any time, a feature that allows peers to act independently of other peers without any sort of state synchronization. The JXTA Protocols Specification does specify that other types of pipes (bidirectional, synchronous, or streaming) might exist in JXTA. However, only the unidirectional asynchronous variety of pipe is required by the specification.
Pipes are described by a Pipe Advertisement using the XML shown in Listing 8.1.
Listing 8.1 The Pipe Advertisement XML
<?xml version="1.0" encoding="UTF-8"?> <jxta:PipeAdvertisement> <Id> . . . </Id> <Type> . . . </Type> <Name> . . . </Name> </jxta:PipeAdvertisement>
The elements of the Pipe Advertisement provide required information that a peer can use to find and connect to a remote peer:
Id—A required element containing an ID that uniquely identifies the pipe. This Pipe ID uses the standard JXTA URN format, as described in JXTA Protocols Specification.
Type—A required element containing a description of the type of connection possible using the pipe. Currently, the reference implementation supports JxtaUnicast, JxtaUnicastSecure, and JxtaPropagate. The JxtaUnicast type of pipe provides a basic connection between one sending endpoint and one receiving endpoint. The JxtaUnicastSecure type of pipe provides the same functionality as the JxtaUnicast type of pipe, except that the connection is secured using the Transport Layer Security (TLS) protocol. The JxtaPropagate type of pipe provides a broadcast connection between many sending endpoints and multiple receiving endpoints.
Name—An optional element containing a symbolic name for the pipe that can be used to discover the Pipe Advertisement using the Discovery service.
Notice that the Pipe Advertisement seems to be missing one important piece of information: a Peer ID. Pipe Advertisements are defined without specifying a specific peer to allow several peers to provide access to a service using the same Pipe Advertisement. The omission of a Peer ID is the reason that pipes must be resolved using the Pipe Binding Protocol.
When a peer wants to send data using a pipe, it needs to find a peer that has already bound a pipe with the same Pipe ID to an endpoint and that is listening for data. The PBP defines two messages to enable a peer to resolve a pipe:
The Pipe Binding Query Message—A message format for querying a remote peer if it has bound a pipe with a matching Pipe ID.
The Pipe Binding Answer Message—A message format for sending responses to the query.
The message formats are all that a peer needs to resolve the ID of a peer that has a bound pipe with a given Pipe ID. As shown in Figure 8.1, when a peer wants to bind to a specific pipe, it sends a Pipe Binding Query Message to all of its known peers and rendezvous peers. Peers respond with a Pipe Binding Answer Message that details whether they have a matching bound pipe.
){kind=small}
Figure
8.1 Exchange of Pipe Binding Messages.
Two important things should be noted from Figure 8.1. First, when Peer 1 creates an input pipe, nothing is sent to the network. Peer 1 simply begins listening on its local endpoints for incoming messages tagged with the Pipe ID specified in the Pipe Advertisement. Second, the Pipe Advertisement doesn't necessarily need to be communicated over the network. Although a Pipe Advertisement usually is discovered using the Discovery service, a Pipe Advertisement could also be hard-coded into an application or exchanged using the Resolver service.
After the receiving end of the pipe has been resolved to a particular endpoint on a remote peer, the peer can bind the other end of the pipe to its local endpoint. This pipe on the local peer is called an output pipe because the pipe has been bound to an endpoint for the purpose of sending output to the remote peer. The bound pipe on the remote peer is called an input pipe because the pipe has been bound to an endpoint for the purpose of accepting input. After the sending peer binds an output pipe, it can send messages to the remote peer.
Only the endpoint location of the pipe on a remote peer must be determined in the binding process to create an output pipe. When creating an input pipe, no binding process is necessary because the local peer already knows that it will be binding the Pipe Advertisement to its local endpoint for the purpose of accepting data.
It is important to reiterate that neither the input pipes nor the output pipes are actually responsible for sending or receiving data. The endpoints specified by the bound pipe are the elements responsible for handling the actual exchange of messages over the network.
In the case of propagation pipes (when the Pipe Advertisement's Type is set to JxtaPropagate), the implementation relies on the multicast or broadcast capabilities of the local endpoint. In this case, the PBP is not required because the sending endpoint doesn't need to find a listening endpoint before it can send data to the network.
The Pipe Binding Query Message
The Pipe Binding Query Message is sent by a peer to resolve the ID of a peer that has bound an input pipe with a specific Pipe ID. Listing 8.2 shows the format of the Pipe Binding Query Message.
Listing 8.2 The Pipe Binding Query Message XML
<?xml version="1.0" encoding="UTF-8"?> <jxta:PipeResolver> <MsgType>Query</MsgType> <PipeId> . . . </PipeId> <Type> . . . </Type> <Cached> . . . </Cached> <Peer> . . . </Peer> </jxta:PipeResolver>
The information sent in the Pipe Binding Query Message describes the pipe that the peer is seeking to resolve and tells whether to use cached information.
MsgType—A required element containing a string that indicates the type of Pipe Binding Message. For the Pipe Binding Query Message, this element is hard-coded to Query.
PipeId—A required element containing the ID of the pipe for which the requesting peer is attempting to resolve a Peer ID.
Type—A required element containing the type of pipe being resolved. This corresponds to the Type field of the Pipe Advertisement, and it can have a value of JxtaUnicast, JxtaUnicastSecure, or JxtaPropagate.
Cached—An optional element that specifies whether the remote peer being queried can use its local cache of resolved pipes to respond to the query. If this parameter is missing, the peer receiving the query assumes that it is allowed to use cached information.
Peer—According to the specification, this optional element specifies the Peer ID of the only peer that should respond to the query. However, the current reference implementation does not send this parameter yet; which peers receive the query is specified by the service interface rather than the protocol.
The reference implementation doesn't define any classes to encapsulate the Pipe Binding Query Message.
The Pipe Binding Answer Message
A peer responds to a Pipe Binding Query Message using a Pipe Binding Answer Message. Note that response might or might not be sent to a given query. Responses received are useful only to update the local peer's cached set of resolved pipes. The Pipe Binding Answer Message comes in two forms: one to indicate that a matching pipe was not found and another to indicate a matching pipe was found. Listing 8.3 shows the format of the Pipe Binding Answer Message.
Listing 8.3 The Pipe Binding Answer Message XML
<?xml version="1.0" encoding="UTF-8"?> <jxta:PipeResolver> <MsgType>Answer</MsgType> <PipeId> . . . </PipeId> <Type> . . . </Type> <Peer> . . . </Peer> <Found>false</Found> <PeerAdv> . . . </PeerAdv> </jxta:PipeResolver>
The elements of the Pipe Binding Answer Message are nearly identical to those of the Pipe Binding Query Message, with the following exceptions:
MsgType—A required element containing a string that indicates the type of Pipe Binding Message. For the Pipe Binding Response Message, this element is hard-coded to Answer.
Found—An optional element that indicates whether a matching Pipe ID was found. If this element is missing, the reference implementation assumes that a peer with a matching Pipe ID was found.
PeerAdv—An optional element containing the Peer Advertisement of the peer that has the matching Pipe ID. If no match was found, this element does not appear in the Pipe Binding Answer Message. The endpoint information required to contact a remote peer using a specific pipe is included as part of the Peer Advertisement.
As with the Pipe Binding Query Message, the reference implementation provides no classes to abstract the Pipe Binding Answer Message.