storescp, dcmrecv and termscu
Moderator: Moderator Team
storescp, dcmrecv and termscu
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
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
-
- Posts: 13
- Joined: Tue, 2018-11-13, 09:05
Re: storescp, dcmrecv and termscu
within storescp https://support.dcmtk.org/docs/storescp.html, you can use:
On dcmrecv https://support.dcmtk.org/docs/dcmrecv.html:-pm --promiscuous
promiscuous mode, accept unknown SOP classes
(not with --config-file)
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.
-
- DCMTK Developer
- Posts: 2049
- Joined: Fri, 2004-11-05, 13:47
- Location: Oldenburg, Germany
- Contact:
Re: storescp, dcmrecv and termscu
...however, the storescp and dcmrecv do not terminate as intended by that private SOP class.
-
- Posts: 13
- Joined: Tue, 2018-11-13, 09:05
Re: storescp, dcmrecv and termscu
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!
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!
Re: storescp, dcmrecv and termscu
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
"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!
-
- DCMTK Developer
- Posts: 2049
- Joined: Fri, 2004-11-05, 13:47
- Location: Oldenburg, Germany
- Contact:
Re: storescp, dcmrecv and termscu
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.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!
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
-
- DCMTK Developer
- Posts: 2049
- Joined: Fri, 2004-11-05, 13:47
- Location: Oldenburg, Germany
- Contact:
-
- DCMTK Developer
- Posts: 2505
- Joined: Tue, 2011-05-03, 14:38
- Location: Oldenburg, Germany
- Contact:
Re: storescp, dcmrecv and termscu
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.
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.
-
- OFFIS DICOM Team
- Posts: 1445
- Joined: Tue, 2004-11-02, 17:22
- Location: Oldenburg, Germany
- Contact:
Re: storescp, dcmrecv and termscu
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.
Who is online
Users browsing this forum: Ahrefs [Bot], Bing [Bot], George and 1 guest