JXTA核心协议之对等机解析协议(PRP)

3.1.1. Introduction
    The Peer Resolver Protocol (PRP) provides a generic query/response interface applications

and services can use for building resolution services. The PRP provides the ability to issue

queries within a peer group and later identifying matching responses. Each query or response is

addressed to a specific named handler. The Resolver Service of each peer group cooperates with

the named handlers to provide the query routing strategies and policies. The named handlers

provide the specific semantics for how the query is distributed and resolved within the peer

group and how responses to the query are handled. In most situations the service or application

has the best knowledge of the group topology and how the query should be routed. A query may be

received and processed by any number of peers withinin the peer group, possibly all, and it is

processed accordingly by a handler if such a named handler is registered on that peer.
    Peers may also participate in the Shared Resource Distributed Index (SRDI). SRDI provides a

generic mechanism JXTA services and applications can utilize a distributed index of shared

resources with other peers that are grouped as a set of more capable peers such as rendezvous

peers. These indices can be used to direct queries in the direction where the query is most

likely to be answered, and repropagate messages to peers interested in these propagated

messages.

2. Resolver Query Message
     The resolver query message is used to send a resolver query to the named handler on one or

more peers that are members of the peer group. The resolver query is sent as a query string to a

specific handler. Each query has a unique Id. The query string can be any string that will be

interpreted by the targeted handler.

Resolver Query Schema:
<xs:element name="ResolverQuery" type="jxta:ResolverQuery"/>
<xs:complexType name="ResolverQuery">
  <xs:sequence>
    <xs:element ref="jxta:Cred" minOccurs="0" />
    <xs:element name="SrcPeerID" type="jxta:JXTAID" />
    <!-- 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="HC" type="xs:unsignedInt" />
    <!-- For historical reasons the query is a whole flattened document -->
    <xs:element name="Query" type="xs:anyType" />
  </xs:sequence>
</xs:complexType>

<jxta:Cred>: The credential of the sender.
<HandlerName>: A string that specifies the destination of this query.
<SrcPeerID>: The id of the peer originating the query (as a URN).
<QueryID>: An opaque indentifier to be used by the querier to match replies. The <QueryID>

should be included in the responses to this query.
<HC>: specifies the number of hops the query has been through The <HC> should be incremented by

each peer that fowards the query.
<Query>: Contains the query.

Resolver Query Example:
<?xml version="1.0"?>
<!DOCTYPE jxta:ResolverQuery>
<jxta:ResolverQuery xmlns:jxta="http://jxta.org">
    <HandlerName>
        urn:jxta:uuid-DEADBEEFDEAFBABAFEEDBABE0000000305
    </HandlerName>
    <jxta:Cred>
        JXTACRED
    </jxta:Cred>
    <QueryID>
        0
    </QueryID>
    <HC>
        0
    </HC>
    <SrcPeerID>
        urn:jxta:uuid-59616261646162614A7874615032503304BD268FA4764960AB93A53D7F15044503
    </SrcPeerID>
    <Query>
        <xml version="1.0"?>

        <!DOCTYPE jxta:DiscoveryQuery>

        <jxta:DiscoveryQuery xmlns:jxta="http://jxta.org">
            <Type>
                0
            </Type>
            <Threshold>
                50
            </Threshold>
            <PeerAdv>
                <?xml version="1.0"?>

                <!DOCTYPE jxta:PA>
                    ... remainder omitted for brevity ...
                </jxta:PA>
            </PeerAdv>
            <Attr> </Attr>
            <Value> </Value>
        </jxta:DiscoveryQuery>
    </Query>
</jxta:ResolverQuery>


3. Resolver Response Message
  A resolver response message is used to send a response to a resolver query message.
Resolver Response Schema:
<xs:element name="ResolverResponse" type="ResolverResponse"/>
<xs:complexType name="ResolverResponse">
  <xs:sequence>
    <xs:element ref="jxta:Cred" minOccurs="0"/>
    <xs:element name="ResPeerID" type="jxta:JXTAID" minOccurs="0" />
    <xs:element name="HandlerName" type="xs:string"/>
    <xs:element name="QueryID" type="xs:string"/>
    <!-- For historical reasons the response is a whole flattened document -->
    <xs:element name="Response" type="xs:anyType"/>
  </xs:sequence>
</xs:complexType>

<jxta:Cred>: The credential of the respondent.
<HandlerName>: Specifies how to handle the response.
<ResPeerID>: The id of the peer originating the response (as a URN).
<QueryID>: The query identifier of the query to which this is a response.
<Response>: The responses.

Resolver Response Example:
<?xml version="1.0"?>
<!DOCTYPE jxta:ResolverResponse>
<jxta:ResolverResponse xmlns:jxta="http://jxta.org">
    <HandlerName>
        urn:jxta:uuid-DEADBEEFDEAFBABAFEEDBABE0000000305
    </HandlerName>
    <jxta:Cred>
        JXTACRED
    </jxta:Cred>
    <QueryID>
        0
    </QueryID>
    <ResPeerID>
        urn:jxta:uuid-59616261646162614A7874615032503304BD268FA4764960AB93A53D7F15044503
    </ResPeerID>
    <Response>
        <?xml version="1.0"?>

        <!DOCTYPE jxta:DiscoveryResponse>

        <jxta:DiscoveryResponse xmlns:jxta="http://jxta.org">
            <Count>
                1
            </Count>
            <Type>
                2
            </Type>
            <PeerAdv>
                <?xml version="1.0"?>

                <!DOCTYPE jxta:PA>

                <jxta:PA xmlns:jxta="http://jxta.org">
                    ... remainder omitted for brevity ...
                </jxta:PA>
            </PeerAdv>
            <Response Expiration="7200000">
                <?xml version="1.0"?>

                <!DOCTYPE jxta:PipeAdvertisement>

                <jxta:PipeAdvertisement xmlns:jxta="http://jxta.org">
                    <Id>
                        urn:jxta:uuid-

59616261646162614E50472050325033D1D1D1D1D1D1D1D1D1D1D1D1D1D1D1D104
                    </Id>
                    <Type>
                        JxtaPropagate
                    </Type>
                    <Name>
                        JxtaTalkUserName.IP2PGRP
                    </Name>
                </jxta:PipeAdvertisement>
            </Response>
        </jxta:DiscoveryResponse>
    </Response>
</jxta:ResolverResponse>

4. Resolver SRDI Message
   The resolver SRDI message is used to send a resolver SRDI message to the named handler on one

or more peers that are members of the peer group. The resolver SRDI message is sent to a

specific handler. The payload string may be any string that will be interpreted by the targeted

handler.
Resolver SRDI Schema:
<xs:element name="ResolverSRDI" type="jxta:ResolverSRDI"/>
<xs:complexType name="ResolverSRDI">
  <xs:all>
    <xs:element name="HandlerName" type="xs:string"/>
    <xs:element ref="jxta:Cred" minOccurs="0"/>
    <xs:element name="Payload" type="xs:anyType"/>
  </xs:all>
</xs:complexType>

<HandlerName>: A string that specifies the destination of this message.
<jxta:Cred>: The credential of the sender.
<Payload>: Contains the payload.

Resolver SRDI Example:
<?xml version="1.0"?>
<!DOCTYPE jxta:ResolverSRDI>
<jxta:ResolverSRDI xmlns:jxta="http://jxta.org">
    <HandlerName>
        urn:jxta:uuid-DEADBEEFDEAFBABAFEEDBABE0000000305
    </HandlerName>
    <jxta:Cred>
        JXTACRED
    </jxta:Cred>
    <Payload>
        <xml version="1.0"?>

        <DOCTYPE jxta:GenSRDI>
                    ... remainder omitted for brevity ...
        </jxta:GenSRDI>
    </Payload>
</jxta:ResolverSRDI>

5. Listener and Element Naming
    The PRP communicates by exchanging Messages using the Endpoint Service. Endpoint Addresses

specify a handler name. The PRP attaches a listener by that name to the Endpoint Service.
    All PRP implementations must use the same scheme for building their handler names. The

convention used by all services of the world peer group is to use the concatenation of the

service name, the peer group ID, and a value unique within the service.

Listener Naming Syntax ABNF:
<JXTARSLVRRSQRY>   ::= <JXTARSLVRNAM> <JXTAIDVAL> <JXTARSLVRQRYTAG>
<JXTARSLVRRSRSP>   ::= <JXTARSLVRNAM> <JXTAIDVAL> <JXTARSLVRRSPTAG>
<JXTARSLVRRSSRDI>  ::= <JXTARSLVRNAM> <JXTAIDVAL> <JXTARSLVRSRDITAG>
<JXTARSLVRQRYTAG>  ::= "ORes"
<JXTARSLVRRSPTAG>  ::= "IRes"
<JXTARSLVRSRDITAG> ::= "Isrdi"
<JXTARSLVRNAM>     ::= "jxta.service.resolver"
<JXTAIDVAL>        ::= See JXTA ID ABNF

The listeners used by the PRP are named as follows:
Queries: jxta.service.resolver[group unique Id string]ORes (ORes is a literal string)
Responses: jxta.service.resolver[group unique Id string]IRes (IResis a literal string)
Srdi: jxta.service.resolver[group unique Id string]Isrdi (Isrdi is a literal string)

Query and response messages are included in messages as elements named as follows:
Queries: [group unique Id string]ORes (ORes is a literal string)
Responses: [group unique Id string]IRes (IRes is a literal string)
Srdi: [group unique Id string]Isrdi (Isrdi is a literal string)

6. Behaviour
Handler Name:
   The Handler Name in PRP messages plays a role similar to that of the handler name in the Endpoint Message addresses: it is a demultiplexing key that specifies how, by which higher-levelprotocol, or by which module, the message is to be processed.
In the Java and “C” reference implementations, the users of the PRP are typically services. Each

instance of a given service (one per peer per group that uses this service) generates a handler

name that is unique on its peer, but will be identical for the instances of this service on

other peers. This is by convention achieved by concatenating the service name (which is unique

in the group), the group id, which is unique in the peer, and a additional parameter which

serves to discriminate between several handlers used by the same service, if needed.
    The handler name is used both to register the appropriate handler for incoming queries or

responses, and as a destination for outgoing queries or responses. For convenience, most clients

of the resolver do define two names: one for propagated messages (mostly queries), and one for

unicast messages (mostly responses).
    The PRP typically uses the Rendezvous Service to disseminate a query to multiple peers or

unicast messages to send queries to specified peers.
    The PRP should refuse, and the existing reference implementations shall refuse the registration of more than one handler with the same name. A service should register for any handler name that it uses as a destination, thereby preventing other services from registering themselves to receive these messages. This means that in principle a service or application that receives queries or responses from a service instance on another peer is de-facto the local instance of that service and should handle these messages as specified. PRP is designed for same-to-same communication, not client-server.
Policies and Quality of Service:
    The PRP does not guarantee peers that define a query handler name will receive that query, nor does it mandate that all peers that define this handler name will receive it. Only a best effort is made at disseminating the query in a way that maximizes the chance of obtaining a response, if one can be obtained.
    There is no guarantee that a response to a resolver query request will be made. It is important to point that response to a ResolverQuery request is optional. A peer is not required to respond.
    There is no guarantee that a Resolver SRDI Message will be honored. It is important to point out that accepting a Resolver SRDI Message is optional. A peer is not required to accept the

message.
    The PRP does not assume the presence of reliable message delivery. Multiple Resolver query

messages may be sent--none, one, multiple or redundant responses may be received.
    The PRP provides a generic mechanism for services to send queries, and receive responses and

SRDI messages. As a service, the reference implementation helps other services by taking care of

all messaging aspects, caching queries responses, and SRDI messages and in forwarding queries,

based on the invoker's decision. The PRP performs authentication, and verification of

credentials and drops incorrect messages.
    The actual task of propagating a query to the next set of peers is delegated to the Rendezvous Protocol. The Rendezvous service is responsible for determining the set of peers that should receive a message being propagated, but never automatically re-propagates an incoming propagated message. It is left to the service (query handler) handling the message to determine if further propogation should be performed. The PRP's policy is the following: if the query handler does not instruct the PRP to discard the query, and if the local peer is a rendezvous, then the query is re-propagated (within the limits of loop and TTL rules enforced by the Rendezvous service).
    In addition, if instructed by the query handler, an identical query may be issued with the local peer as the originator.