Storage commitment

Storage commitment (the Storage Commitment Push Model) lets one system ask another to confirm it has taken responsibility for instances, so it can safely delete its own copies. Routes does it both ways.

Modalities asking the router

On a source, tick Offer storage commitment:

• Commit when: delivered to every destination of the route (default), or received and queued on disk.
• The result goes on a new association to the requester. By default to its address and calling AE title; the port must be the modality’s own SCP port.
• A request may reach a different node from the one that received the images (behind a load balancer): instances the node does not know are looked up in the central history.
• Instances still unresolved after the timeout are reported as failed. Requests survive node restarts.

The router asking destinations

On a DICOM destination, tick Request storage commitment:

• Delivered instances are asked about in batches (up to 500, after at most 5 seconds).
• The destination answers on the same association (kept open briefly, 10 s by default) or on a new association to the node’s listen port, addressed to the router’s AE title. Register the router (its AE title, each node’s address, the port) as a storage commitment peer on the destination.
• Committed instances show as Committed in the history. Instances the destination could not commit are sent again from the resend cache (up to twice; keep the cache on), then recorded as not committed, as are those without a result in time.
• A modality whose source commits when delivered gets its own commitment once such destinations have committed.

The Nodes tab shows committed, awaiting and failed counts per destination.