LAUREL BRIDGE

Program Class

DICOM Connectivity Framework V3.4
Storage commitment service class provider example which should be run with the StorageCommitmentSCU example.
Inheritance Hierarchy

SystemObject
  LaurelBridge.DCFExamples.StorageCommitmentSCPProgram

Namespace:  LaurelBridge.DCFExamples.StorageCommitmentSCP
Assembly:  StorageCommitmentSCP (in StorageCommitmentSCP.exe) Version: DCF34 r13043 DCF_3_4_56_20220408 NetFramework
Syntax

C#
public class Program

The Program type exposes the following members.

Constructors

  NameDescription
Public methodProgram
Initializes a new instance of the Program class
Top
Methods

  NameDescription
Public methodStatic memberMain
Main entry point for StorageCommitmentSCP.
Top
Remarks

Storage Commitment is a DICOM service which allows the SCU (client) (e.g., the StorageCommitmentSCU example) to check that DICOM instances sent to a SCP (server) have been stored successfully by the server before deleting or doing something else with its own copies.

An instance is stored normally by the SCU using C-STORE (Storage Commitment is not used to transfer the images themselves), but then the SCU sends a storage commitment request in the form of an N-ACTION asking the SCP to report back once the the listed images have been safely committed. The SCP reports this confirmation asynchronously using N-EVENT-REPORT.

One important subtlety to note is that the N-EVENT_REPORT is sent by the SCP asynchronously to the SCU; for the storage commitment transaction the roles are reversed: the SCU (server) receives the storage commitment request message from the SCP (client).

The Storage Commitment message flow looks like this for an SCU named "A" and an SCP named "B":

  1. SCU(A) is an N-EVENT-REPORT server that starts up and listens on a particular port for N-EVENT-REPORT requests that will indicate completed Storage Commitment events.
  2. SCP(B) is an N-ACTION server that starts up and listens on a particular port for N-ACTION requests that represent Storage Commitment requests.
  3. SCU(A) creates an association and sends an N-ACTION request to SCP(B).
  4. SCP(B) sends an N-ACTION response back to SCU(A) that indicates the request has been received.
  5. SCP(B), at the completion of the N-ACTION request, creates a separate association and sends an N-EVENT-REPORT request to SCU(A) to indicate completion of the N-ACTION request.
  6. SCU(A) sends an N-EVENT-REPORT response back to SCP(B) to acknowledge that the event indication has been received.
  7. The two associations are closed independently.
See Also

Reference