storescp, dcmrecv and termscu

All other questions regarding DCMTK

Moderator: Moderator Team

Post Reply
Message
Author
mal11
Posts: 2
Joined: Thu, 2022-04-21, 16:31

storescp, dcmrecv and termscu

#1 Post by mal11 »

Hello.
Did anyone ever attempt to add support to storescp or dcmrecv for the private SOP class sent by termscu?
it might be a useful feature for scripting/glue applications.

mlewis

Geert Vandenbussche
Posts: 13
Joined: Tue, 2018-11-13, 09:05

Re: storescp, dcmrecv and termscu

#2 Post by Geert Vandenbussche »

within storescp https://support.dcmtk.org/docs/storescp.html, you can use:
-pm --promiscuous
promiscuous mode, accept unknown SOP classes
(not with --config-file)
On dcmrecv https://support.dcmtk.org/docs/dcmrecv.html:
Basically, the dcmrecv application supports all Storage SOP Classes as an SCP, including private ones. This requires, however, that a corresponding association negotiation profile is loaded from a configuration file. The format and semantics of this configuration file are documented in asconfig.txt.
By default, that means if no association negotiation profile is loaded, dcmrecv only supports the Verification SOP Class as an SCP (with default transfer syntax, i.e. Implicit VR Litte Endian).
In the future, there might be additional options that allow for specifying the list of supported Presentation Contexts (i.e. combination of SOP Class and Transfer Syntaxes) directly, i.e. without loading a configuration file.

Michael Onken
DCMTK Developer
Posts: 2048
Joined: Fri, 2004-11-05, 13:47
Location: Oldenburg, Germany
Contact:

Re: storescp, dcmrecv and termscu

#3 Post by Michael Onken »

...however, the storescp and dcmrecv do not terminate as intended by that private SOP class.

Geert Vandenbussche
Posts: 13
Joined: Tue, 2018-11-13, 09:05

Re: storescp, dcmrecv and termscu

#4 Post by Geert Vandenbussche »

Michael,

What do you mean by 'do not terminate as intended by that private SOP class'?

(Opposite way: I use DcmSCU to send private objects to PACS SCP's, didn't experience any problems with this so far.)

Thanks!

mal11
Posts: 2
Joined: Thu, 2022-04-21, 16:31

Re: storescp, dcmrecv and termscu

#5 Post by mal11 »

https://support.dcmtk.org/docs/termscu.html

"The termscu application implements a Service Class User (SCU) for DCMTK's private Shutdown SOP Class. It tries to negotiate this private Shutdown SOP Class with a Service Class Provider (SCP) which (if this feature is implemented) will immediately shutdown after refusing the association. The application can be used to shutdown some of DCMTK's server applications."

IF THIS FEATURE IS IMPLEMENTED

Geert Vandenbussche wrote: Mon, 2022-04-25, 19:48 Michael,

What do you mean by 'do not terminate as intended by that private SOP class'?

(Opposite way: I use DcmSCU to send private objects to PACS SCP's, didn't experience any problems with this so far.)

Thanks!

Michael Onken
DCMTK Developer
Posts: 2048
Joined: Fri, 2004-11-05, 13:47
Location: Oldenburg, Germany
Contact:

Re: storescp, dcmrecv and termscu

#6 Post by Michael Onken »

Geert Vandenbussche wrote: Mon, 2022-04-25, 19:48 Michael,

What do you mean by 'do not terminate as intended by that private SOP class'?

(Opposite way: I use DcmSCU to send private objects to PACS SCP's, didn't experience any problems with this so far.)

Thanks!
The private Shutdown SOP Class was introduced in DCMTK dcmqrscp tool (mini PACS server). It allows a client to shut down the dcmqrscp PACS server by just negotiating the SOP Class.

If you use storescp and dcmrecv options to make those tools accept the private shutdown SOP Class, they will accept the SOP class but will not shut down, i.e. they will stay online and keep listening.

Or are you referring to something else?

Best regards,
Michael

Michael Onken
DCMTK Developer
Posts: 2048
Joined: Fri, 2004-11-05, 13:47
Location: Oldenburg, Germany
Contact:

Re: storescp, dcmrecv and termscu

#7 Post by Michael Onken »

mal11 wrote: Mon, 2022-04-25, 21:58 IF THIS FEATURE IS IMPLEMENTED
Exactly! :)

J. Riesmeier
DCMTK Developer
Posts: 2501
Joined: Tue, 2011-05-03, 14:38
Location: Oldenburg, Germany
Contact:

Re: storescp, dcmrecv and termscu

#8 Post by J. Riesmeier »

By the way, the reason why we've implemented support for the private shutdown SOP Class to dcmqrscp and dcmpsrcv was that these tools are started as background processes by DICOMscope and need to be terminated "in a friendly way" when DICOMscope is closed. The tool termscu has just been implemented for testing purposes, i.e. to test this feature without using DICOMscope.

To answer the question of the OP, at least in part: for dcmrecv and other SCPs based on the DcmSCP class, it would certainly make sense to implement support for the private shutdown SOP class in the base class. This shouldn't be too complicated since DcmSCP already provides a stopAfterCurrentAssociation() method, which could be used for this purpose.

Marco Eichelberg
OFFIS DICOM Team
OFFIS DICOM Team
Posts: 1437
Joined: Tue, 2004-11-02, 17:22
Location: Oldenburg, Germany
Contact:

Re: storescp, dcmrecv and termscu

#9 Post by Marco Eichelberg »

As the author who "invented" that private SOP class 20 years ago, I have to add that at the time I did not see the drawbacks of that approach. Today I would probably do it differently:
  • If you are running the server process (e.g. dcmqrscp or dcmpsrcv) in TLS mode and the certificate expires, you cannot properly shutdown the tool anymore because the TLS negotiation fails, and that happens before the private SOP class UID is sent
  • On Windows, the approach prevents proper multiprocessing. If you look at how the --fork option is implemented in storescp, on Windows this works by creating a new process for each incoming network connection and then handing over the network socket to the child process. Now the private SOP class would be received by the child, while the parent process would happily continue to accept new incoming connections. If we do the DICOM network association in the parent, we have no way of handing over a well-defined state to the child process.
I think a solution based on some form of IPC would be better suited, but implementing that portably across platforms is unfortunately not trivial.

Post Reply

Who is online

Users browsing this forum: Ahrefs [Bot], Google [Bot] and 1 guest