How to populate request MessageId when deriving from DcmScu

[jogerh]

I am implementing a class that inherits from DcmScu. This class is going to send a DIMSE message using DcmScu::sendDIMSEMessage. sendDIMSEMessage requires a T_DIMSE_Message message object which aggregates a MessageID. To ensure that the MessageID does not conflict with any of the message IDs that other DcmScu functions sends, I want to use DcmScu::nextMessageID, but this is a private function.

What is the appropriate way to generate message IDs for DIMSE messages in classes that inherit from DcmScu?

Any help is highly appreciated.

Jøger Hansegård
GE Vingmed Ultrasound

[J. Riesmeier]

Hi Jøger,

welcome to the DCMTK forum and thank you for your report.

As far as I understand, you want to implement new network functionality in the derived class that does not call any of the existing sendXXXRequest() methods. That means, you want to fill the low-level networking data structures directly and, therefore, need access to the next available Message ID. Is this correct? In this case, it would probably make sense to move the nextMessageID() method from the "private" to the "protected" section of the DcmSCU class.

Regards,
Jörg

[Michael Onken]

Hi Jøger,

DcmSCU uses nextMessageID() to get the message ID to be used when sending any DIMSE message over the network, i.e. when the user makes use of the sendECHORequest(), sendSTORERequest() and so on. As long as you use those methods the message ID in your derived class is fine.

My feeling is that nextMesssageID() should stay private unless there is a very good reason to make it protected. So my question is why you want to use sendDIMSEMessage() directly and not use the high level methods? If a feature is missing on the high level calls we could maybe extend them.

Another way to fix your use case is to move the call to nextMessageID() into sendDIMSEMessage() instead, which would probably make the most sense to me. Then it would not matter if you call sendDIMSEMessage() for your custom use case or use the high level API send...Request(). I need to check whether this change in DcmSCU is really possible, though.

Best regards,
Michael

[jogerh]

Thank you Michael and Jörg,

I am currently implementing support for sending N-CREATE and N-SET requests and receiving the responses. These service elements are not supported through the high level DcmScu API as far as I can tell. So Michael, you have the correct understanding of the problem.

For my purpose it would be perfect to have public high level functions to handle these messages, but this could of course be in conflict with other interests. Still, allowing DcmScu::sendDIMSEMessage to populate the message ID would be a useful feature. With the current API, it does not seem possible to use DcmScu::sendDIMSEMessage correctly in the general sense, even if it is available to derived classes as a protected function. Making nextMesssageID protected would be a workaround that would make sendDIMSEMessage possible to use correctly, but I agree this is maybe not an optimal solution as it unnecessarily exposes an implementation detail.

Do I understand the situation correctly, or are there other ways of approaching the problem that I missed?

Thanks,
Jøger Hansegård
GE Vingmed Ultrasound

[Michael Onken]

Hi Jøger,

we should then introduce sendNCREATERequest() and sendNSETRequest() as public methods. If you write the code anyway, could you send me a patch as a starting point? I would then make modifications as necessary to make it part of DCMTK.

Also, I will check whether we can safely move nextMessageID() to sendDIMSERequest() which would solve your problem independent from the fact whether you want to provide a patch to DCMTK or not.

Best regards,
Michael

[jogerh]

Please see https://github.com/DCMTK/dcmtk/pull/52. Maybe we could discuss a bit there?

[Michael Onken]

Hi Jøger,

awesome, I'll review that in the next days and let you know.

Best regards,
Michael

[jogerh]

Hi Michael,

How is the progress on the review?

Thanks,
Jøger

[Michael Onken]

Hi Jøger,

I did not find time so far, sorry, I hope it will be done by the end of the week.

Best regards,
Michael

[jogerh]

Hi again Michael,

Have you had time to look at the pull request yet?

Thanks,
Jøger

[Michael Onken]

Hi Jøger,

I got ill last week and start to work this week again. Sorry for the delay.

Best regards,
Michael

[Michael Onken]

Please see my comments on GitHub.

[jogerh]

Thank you Michael!

Then I will go ahead and implement N-SET following a similar pattern.

[Michael Onken]

Great!

[jogerh]

Hi Michael,

I am struggling a bit with GitHub now, but please see https://github.com/DCMTK/dcmtk/pull/57

It contains a draft implementation for the N-SET support in DcmScu. I am a bit unsure if I understood N-SET correctly, so please feel free to comment.