Describes the general messageflow in communication between the Bit Repository components.

An operation in the Bit Repository is a two-phase process.

The first phase is the identification phase. A client broadcasts an Identify Request message, and all relevant components that can answer the request must reply with an Identify Response message. The client can then select the relevant components for the operation.

The second phase is the operation phase. The client sends an Operation Request message to the selected components. The component performs the operation and sends back zero or more Operation Progress Response messages and finally an Operation Final Response.

If the Operation Request contains data (such as Put or Replace) a reference to the data, as described in File Exchange Protocol is included.

If the Operation Final Response contains data (such as Get, GetFileIDs, GetChecksums, GetAuditTrails) a reference to the data, as described in File Exchange Protocol can be included. In some cases it may also be inlined in the messages.

The illustration below shows an example of a conversation.

Normal message flow 

  1. Identify requests: The client initiating an operation should start by sending an Identify request  to the broadcast Destination. The identify request asks all pillars and/or contributors who is capable and able to perform the operation to reply. The request includes the Destination whereto the pillars/contributors should send their responses.
  2. Identify responses: All pillars and/or contributors who support the operation and for whom the received Identify request is relevant, send responses back containing a Destination used by the client to send messages directly to the pillar/contributor. The responses can also include additional information about the pillars ability to respond. E.g. expected delivery time of a file.
  3. The client chooses which pillars to use for the operation
  4. Operation request: The client sends an Operation request message to each pillar/contributor chosen for the operation, requesting the specific operation to be performed. 
  5. Progress response: Each pillar can send Progress responses regarding the status of the operation process. The first progress message will typically be an 'Operation accepted' response'. It is not mandatory
  6. Final response: When a pillar has finished performing the requested operation, it sends an Final Response. The final response contains the final status of the operation, failure or success. It may also contain the result of the operation or information on where to get the results. 

The message flow above is described in a general form. Each type of message mentioned above is specific to the given operation type. The specific operations and their messages is listed on the Protocol messages page.

Other flows