How to populate request MessageId when deriving from DcmScu

All other questions regarding DCMTK

Moderator: Moderator Team

Message
Author
jogerh
Posts: 37
Joined: Mon, 2022-02-28, 08:55

Re: How to populate request MessageId when deriving from DcmScu

#31 Post by jogerh » Thu, 2022-06-30, 11:09

Thank you so much! I hope for the best, and look forward to enjoying the N-SET experience.

jogerh
Posts: 37
Joined: Mon, 2022-02-28, 08:55

Re: How to populate request MessageId when deriving from DcmScu

#32 Post by jogerh » Tue, 2022-10-04, 15:57

Hi again Michael,

I once again stumbled across a problem caused by the private DcmSCU::nextMessageID function. DcmSCU appears to be designed with extensibility through inheritance in mind. If this is the intent, I believe that the nextMessageID must be made protected instead of private, as there are no other way to override some of the virtual functions in a meaningful way.

I have therefore created https://github.com/DCMTK/dcmtk/pull/70 to address this issue. Please have a look and see if it can be merged to master.

Thanks,
Jøger Hansegård

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

Re: How to populate request MessageId when deriving from DcmScu

#33 Post by Michael Onken » Tue, 2022-10-04, 17:01

Hi Jøger,

Your assumption is correct - another assumption was that there is no need to manually choose a Message ID at all, what is your use case to do so?

Best regards,
Michael

jogerh
Posts: 37
Joined: Mon, 2022-02-28, 08:55

Re: How to populate request MessageId when deriving from DcmScu

#34 Post by jogerh » Tue, 2022-10-04, 18:09

Hi Michael,

The general issue is that it is impossible for a derived class to reimplement DcmSCU::sendMOVERequest or any of the other sendXXXRequest functions as long as the nextMessageID function is private.

The specific issue, is that we want to get hold of the message ID before the C-MOVE request is sent to the server. This message ID can be used by the store SCP and matched with the 'Move Originator Message ID' (0000,0110) from the incoming C-STORE request. If an application has two instances of DcmSCU, that are concurrently sending C-MOVE requests, we could then differentiate between the incoming C-STORE requests based upon the message ID from the MoveSCU, and the 'Move Originator Message ID', as long as this is provided by the PACS. For example, the images could be stored to different directories for the two different DcmSCUs.

Does this answer your question Michael?

Thanks
Jøger

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

Re: How to populate request MessageId when deriving from DcmScu

#35 Post by Michael Onken » Wed, 2022-10-05, 13:55

Hi,

yes, I understand, thanks for pointing me to the Move Originator Message ID which I did not have in mind.
I pushed the patch to our internal testing branch and it will be available the next time we forward this to master.

Thanks for contributing :)

Best regards,
Michael

jogerh
Posts: 37
Joined: Mon, 2022-02-28, 08:55

Re: How to populate request MessageId when deriving from DcmScu

#36 Post by jogerh » Wed, 2022-10-05, 14:13

Great news! Thank you Micahael.

Jøger

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest