Visit MetaAgility Home Page Visit MetaAgility Home Page

X3P Protocol Description

This is a description of the abstract high level X3P application protocol.

X3P Protocol Objectives and Functionality

The aim is to reliably establish extensible peer-to-peer sessions, where each peer has control over the authentication of the other peer through back-channel communication. Peers should be able to refuse the establishment of sessions with non-authorised peers.

Once a session has been established the initiating peer must propose a desired application protocol. The responding peer may accept the proposal or, if it is refusing, may suggest an alternative application protocol.

Once a application protocol has been agreed (and bound to corresponding services) communication may continue using extended application specific messages.

Established sessions may be closed by either peer.

Detailed X3P Assumptions

  • Assume two peer services: peer-A and peer-B.
  • Assume peer-A can communicate with peer-B on an independent channel with address B.
  • Assume peer-B can communicate with peer-A on an independent channel with address A.
  • Assume each communication is of client-server style, i.e. a defined request message can be sent reliably and a reliable reply can be received or else you get reliable error handling.
  • Assume both request messages and reply messages have a common structure with a parameterised header and an optional body containing the message payload.

Details on How to Establish an X3P Session

  1. Initial condition: no session between peer-A and peer-B exists.
  2. Peer-A generates a unique session token: token-X.
  3. Peer-A sends an open-session-request message to address B. The message contains
    • the back-channel address A and
    • the session token token-X.
  4. Peer-B receives the message. Since the message has no reference to an existing session, the back-channel address A is tested for authorisation.
  5. If the back-channel address A is unauthorised, peer-B generates an empty error reply to the message.
  6. If the back-channel address A is authorised, peer-B
    1. generates a corresponding unique session token: token-Y
    2. and sends a session confirmation message with token-Y and token-X on the back-channel to address A.
  7. Peer A receives the two tokens on the back-channel and identifies the session token token-X and saves the two tokens as a token pair. The pair defines the new session.
  8. If the own session token is identified, peer-A replies OK to the session confirmation message, or else replies to peer-B with an error report.
  9. When peer-B receives the OK reply it also saves the token pair as its record of the new session.
  10. Peer-B then replies OK to the original open-session-request message, or else replies to peer-A with an error report.

If all is OK, then from now on peer-A can send messages tagged with token-Y on address B and they are recognised by peer-B to belong to the established session. In the same way peer-B can send messages tagged with token-X on address A and they are recognised by peer-A to belong to the session in question. A message with a recognised session token is called a session message.

If a peer does not recognise the session token it replies with an error report. The sending peer must then assume the session is closed and will have to try to establish a different session.

Closing an Established X3P Session

Both peer-A and peer-B can request the session to be closed by sending a session message with a close-session request. A closed session cannot be reopened.

Details on How to Extend an Established X3P Session

  1. Peer-A sends a request-extension session message specifying the required application protocol to address B.
  2. Peer-B identifies the request and checks if the proposed application protocol is acceptable.
    • If so, it binds the corresponding functional service to the session and replies OK.
      • When peer-A receives the OK reply, it binds the corresponding functional service to its end of the session.
    • Otherwise, if the proposed application protocol is not acceptable, peer-B may optionally suggest an alternative application protocol by sending an alternative-extension session message on the back-channel to peer-A. In any case peer-B replies with an error report to the original request.
      • When peer-A receives the error report, it may check if peer-B has suggested an alternative application protocol (in an alternative-extension message). Given any proposal or not, the negotiation resumes at point 1.

Application Messages on an Extended X3P Session

Either peer may send two types of application session messages on extended sessions:

  • extended-request messages to which an extended-reply is expected from the application service on the corresponding session back-channel.
  • extended-message to which no application reply is expected on the session back-channel.

Both the extended-request and the extended-message may be directly replied to by the peer service with an error report. Also the extended-reply session message may result in an error response from the service at the other end of the back-channel.

The body (payload) of session messages in extended sessions is passed on the corresponding application service, which is responsible for decoding the body and generating any reply on the peer back-channel. Alternatively, the application service may generate error reports, which are returned as direct replies to the original message.

X3P Implementation

The above abstract protocol has been implemented over HTTP using HTTP headers to express protocol details and the HTTP content to carry message payloads.

Back to X3P protocol overview.

We would appreciate any comments or questions.
Include your details if you wish to be contacted.

2008-08-07 19:57

Home of

Copyright (2008) MetaAgility Knowledge Engineering.