Use Case ID: UC20.0
Use Case Name: Reply to Peer Request
Created by: jwh
Date Created: Thu Jul 19 22:00:56 2001
Last Updated by: jwh
Date Last Updated: Thu Jul 19 22:00:56 2001

Actor: User Application

Goal: Send a reply

Description: Send a reply to a request.

Preconditions:

  1. The engine must be started.
  2. The reply must be to a request that hasn't been replied to already.
Post conditions:
  1. The engine marks the request as replied to.

Priority: High

Related Use Cases:

UC15.0 - Send Peer Request
UC16.0 - Send Peer Request Async
UC17.0 - Cancel Peer Request
UC21.0 - Cancel Reply to Peer Request

Notes and Issues:

  1. The reply is not guaranteed unless specified by the peer framework.

Event Flow:

  1. The application registers to be informed when the reply has been sent.
  2. The application builds a generic reply message (see UC25.0 - Build Peer Message).
  3. The application asks the engine to transmit a reply to a peer.
  4. The engine constructs an appropriate message.
  5. The engine sends the reply to the peer.
  6. The engine marks the request as replied to.
  7. When the transmission is complete, the engine informs the registered application.
  8. The application removes its registration to listen for the message sent confirmation.
Alternate Flows:

UC20.1 Engine is not started

  1. The application asks the engine to transmit a reply to a peer.
  2. The engine returns an error that the it has not been started.

UC20.2 The peer is not available

  1. The application registers to be informed when the reply has been sent.
  2. The application builds a generic reply message (see UC25.0 - Build Peer Message).
  3. The application asks the engine to transmit a reply to a peer.
  4. The engine constructs an appropriate message.
  5. The engine determines that the peer is not currently available.
  6. The engine returns an error that the peer is not available.

UC20.3 The request has already been replied to by the peer

  1. The application registers to be informed when the reply has been sent.
  2. The application builds a generic reply message (see UC25.0 - Build Peer Message).
  3. The application asks the engine to transmit a reply to a peer.
  4. The engine constructs an appropriate message.
  5. The engine determines that the reply has already been sent.
  6. The engine returns an error that the reply has already been sent.

Sequence Diagrams:

Event Flow Sequence Diagram

Revision History
Name Date Reason for Change Version
       

$Id: UC20.0.html,v 1.6 2001/07/26 17:52:19 james Exp $