How to Cancel Retrieve of Images

Message

focus · #1 Post by **focus** » Fri, 2010-07-23, 20:16

Hello,

We are developing on our viewer that the user can cancel retrieve of DICOM files at any moment.

We have tested our code succesfully with DCM4CHEE, using DIMSE_sendCancelRequest method the retrieve of DICOM files is cancelled, but we have another PACS to test that this doesn't accept cancelRequest.

With this PACS that doesn't accept cancelRequests, How Can We cancel the retrieve of DICOM Files?

Thanks.

#2 Post by **Michael Onken** » Sun, 2010-07-25, 12:12

Hi,

Then you only can choose the unpolite way - abort the association

Best regards,
Michael

focus · #3 Post by **focus** » Mon, 2010-07-26, 07:34

Thanks for your answer,

I have some doubts about how we have to abort the connection.

Based in the movescu code Where have we to abort the connection? in storeSCPCallback method after retrieve an image, in moveCallback method where is sent the cancelRequest, ..... in another point ?

Another doubt is if we have to abort only the association network connection (the connection we receive the images), or we have to abort this connection and the connection with PACS (the connection which we receive c-move response).

Finally for curiosity It's mandatory to implement cancelRequest on PACS or It's optional, I have been searching it in DICOM documentation but I haven't found.

Thanks for your help.

#4 Post by **Michael Onken** » Mon, 2010-07-26, 08:52

Hi,

you can abort the association wherever you like. Even more unpolite is just to drop the tcp connection. However, also for the abort request there will be no response (unlike association release), so that is the better way to do it.

C-FIND-CANCEL support is mandatory for Query/Retrieve SCPs, see for example part 4 "C.4.1.3.1 Baseline behavior of SCP":

If the SCP receives C-FIND-CANCEL indication before it has completed the processing
of the matches it shall interrupt the matching process and return a status of Canceled.

Best regards,
Michael

focus · #5 Post by **focus** » Mon, 2010-07-26, 09:20

But which connection We have to abort ? Only the association network connection (the connection we receive the images), or we have to abort this connection and the connection with PACS (the connection which we receive c-move response).

Thanks.

#6 Post by **Michael Onken** » Mon, 2010-07-26, 09:57

Ah sorry, I thought you want to cancel the c-find phase where you only receive index information in the responses, not images.

For canceling image transmission, you send a c-move-cancel on the first connection, i.e. the one where you also sent the the c-move-request. If you then keep receiving images anyway, you may abort the image (i.e. the second) connection. That should lead to an error on your first connection. If the first connection runs into a timeout, you could also abort that one.

In the standard, it is required that the SCP should stop sending images if the c-move-cancel was received on the fist connection, see e. g. C.1.4 Service Definition:

The SCU may cancel the C-MOVE service by issuing a C-MOVE-CANCEL
request at any time during the processing of the C-MOVE. The SCP terminates
all incomplete C-STORE sub-operations and returns a status of Canceled.

Best regards,
Michael

focus · #7 Post by **focus** » Mon, 2010-07-26, 21:05

First of all Thanks Michael for your answers.

I have been testing what you said of abort the association. For DCM4CHEE aboting the connection for incomig images (network association) works well and it's not necessarily to abort the other association with PACS where we receive the c-move responses, DCM4CHEE seems that close automatically this association (where we receive c-Move responses) when receive an abort on the other association (network association).

But we have another PACS to test, that with this it's necessary to abort the association where we receive the c-move responses too. This PACS doesn't close it when the association where we receive the images (association network) is aborted by us.

Our question is mandatory by DICOM if a PACS receive an abort of the association where the images are retrieved (network association), that this close the other association (where we receive c-move response) ? or it depends of PACS implementation.

Another thing that we have tested with this PACS is to abort only the association of incoming images, and wait for timeout changing the type of blocking of DIMSE_moveUser method to DIMSE_NONBLOCKING, but it seems we are afected by the same issue of viewtopic.php?t=2010

Thanks

#8 Post by **Michael Onken** » Tue, 2010-07-27, 08:57

Hi,

as I quoted from the standard way to do is that:

The SCU may cancel the C-MOVE service by issuing a C-MOVE-CANCEL
request at any time during the processing of the C-MOVE. The SCP terminates
all incomplete C-STORE sub-operations and returns a status of Canceled.

If you choose to abort the image transmission association first, then you should get an error on the first, c-move connection since the images could not be delivered. Whether after the error the PACS ends the association by release or abort immediately, is not specified.

If you abort the c-store connection with the images, then the behaviour is implementation specific as stated in the standard (C.4.2.3.1 Baseline Behavior of SCP)

If the association on which the C-MOVE operation was issued is abnormally terminated,
then it will not be possible to issue any further pending responses nor a final response, nor will
C-MOVE-CANCEL requests be received. The behavior of the C-MOVE SCP acting as a CSTORE
SCU is undefined in this condition. Specifically, whether or not any uncompleted CSTORE
sub-operations continue is undefined.

For the time out issue: Could you please try to build your movescu binary from the current snapshot source code? There were some small changes regarding time outs and I want to be sure that the problem is not solved already.

Best regards,
Michael

focus · #9 Post by **focus** » Tue, 2010-07-27, 19:09

Thans Michael for your help.

I will try it during this august to compile the lastest snapshot of dcmtk to test if the problems with the timeout are solved.

Which is the purpose of this snapshot of dcmtk 3.5.5? It's supposed that it can be used only for testing enviroments? for production enviroments Will be better we wait to the final release of 3.5.5? In this case Have you a approximately date when the final versions of 3.5.5 will be released ?

#10 Post by **Jörg Riesmeier** » Tue, 2010-07-27, 20:00

Version 3.5.5 is the snapshot, see the following announcement. The date for the next release (most probably version 3.6.0) is not yet known.

focus · #11 Post by **focus** » Thu, 2010-09-02, 20:31

Michael Onken wrote: For the time out issue: Could you please try to build your movescu binary from the current snapshot source code? There were some small changes regarding time outs and I want to be sure that the problem is not solved already.

Hi Michael,

I have compiled the lastest snapshot of dcmtk in Windows, and the issue with the dimse timeout it seems it isn't solved yet, if you execute movescu with -td option (dimse timeout ) movescu immediately finish.

The command I execute with movescu is

Code: Select all

movescu -P 192.168.0.104 11112 -aet WORKSTATION1 -aec DCM4CHEE +P 4006 -td 10 -v move.dcm

With verboses mode It generates this output

Code: Select all

I: Requesting Association
I: Association Accepted (Max Send PDV: 16340)
I: Sending Move Request: MsgID 1
I: Request:
I:
I: # Dicom-Data-Set
I: # Used TransferSyntax: Little Endian Explicit
I: (0008,0052) CS [STUDY]                                  #   6, 1 QueryRetrieveLevel
I: (0020,000d) UI [1.3.46.670589.11.0.0.11.4.2.0.5479.5.4852.2007061715550468620] #  62, 1 StudyInstanceUID
I:
E: Move Request Failed: 0006:0207 DIMSE No data available (timeout in non-blocki ng mode)
E: Move SCU Failed: 0006:0207 DIMSE No data available (timeout in non-blocking m ode)
I: Aborting Association

The issue appears with DIMSE-NON-BLOCKING Mode.

Thanks.

#12 Post by **Michael Onken** » Thu, 2010-09-09, 10:34

Hi,

Does a timeout in non-blocking mode make sense at all since in non-blocking mode you usually expect that there is already data waiting to be processed. In blocking mode, you block the function blocks (waits) as long as there is no incoming data. This waiting time can be adjusted by the DIMSE timeout (-td) that you are using.

Best regards,
Michael

focus · #13 Post by **focus** » Thu, 2010-09-09, 18:43

I don't know if I'm doing something wrong, but if you put "-td 10", is expected that movescu if not receive any data will wait 10 seconds until exit by timeout, no?

The problem if you put for example -td 10, that movescu do the timeout immediately, It doesn't wait 10 seconds specified as a command parameter.

#14 Post by **Michael Onken** » Fri, 2010-09-10, 09:04

Hi,

Did you try to use blocking mode instead with that timeout?

Michael

P.S: Not sure myself about the timeout and the blocking modes -- Jörg and I will look into the toolkit and provide a definitive answer for that

#15 Post by **Jörg Riesmeier** » Fri, 2010-09-10, 16:29

I can confirm that there seems to be an issue with the DIMSE timeout (non-blocking mode) for the movescu.

DICOM @ OFFIS

How to Cancel Retrieve of Images

How to Cancel Retrieve of Images

Who is online