[Q] Difference between C-GET and C-MOVE

Klaus Claassen

unread,

Aug 30, 1995, 3:00:00 AM8/30/95

to

Hi,
I am about to implement a Query/Retrieve SCP and
wonder if the SCP must accept both C-GET and C-MOVE
requests. What is the difference anyway?
Any help will be appreciated,
thanx in advance,
Klaus

Henrik B}kman CSD

unread,

Aug 31, 1995, 3:00:00 AM8/31/95

to

I am about to implement a Query/Retrieve SCP and
wonder if the SCP must accept both C-GET and C-MOVE
requests. What is the difference anyway?

I suppose your question is about when C-GET and C-MOVE are used
in the Q/R service class. I think this is the only service class where
C-MOVE is used?

The technical difference is that the C-STORE operation must use the SAME
association as the C-GET but a DIFFERENT association as the C-MOVE.

The functional difference is that the SCP of the C-STORE must be the
same AE as the SCU of the C-GET but the SCP of the C-STORE could be
another AE than the SCU of the C-MOVE.

C-GET and C-MOVE, together with the information model, defines different
SOP's so you must NOT support both if you don't want that.

Yours sincerely

--
----------------------------------------------------------------------
Henrik Bakman Adress: Box 311 Tel: +46 18 181044
System Manager 751 05 UPPSALA Fax: +46 18 521270
Computing Science Dep. SWEDEN Email: h...@csd.uu.se
Uppsala University Minicall: 0740-202509

Walter O. Haas

unread,

Sep 1, 1995, 3:00:00 AM9/1/95

to

In article <421l7...@uni-erlangen.de>,

Klaus Claassen <ea...@fim.uni-erlangen.de> wrote:
>I am about to implement a Query/Retrieve SCP and
>wonder if the SCP must accept both C-GET and C-MOVE
>requests. What is the difference anyway?

Sending a C-GET-RQ causes it to initiate a C-STORE-RQ on the same
association (but a different presentation context) as the C-GET-RQ was
sent on.

C-MOVE causes the initiation of C-STORE-RQ(s) on a different association.

You can accomplish the function of a C-GET by doing a C-MOVE to
yourself, so I consider C-GET to be redundant. I'm pretty sure that
I ran into wording in the standard that described it as "deprecated"
but I can't find that at the moment. I don't plan to implement C-GET
myself.

-- Walt

Herve Garfagni

unread,

Sep 4, 1995, 3:00:00 AM9/4/95

to

C-MOVE and C-GET semantics is described in Annex C of DICOM Part 4.

Section C.4.2:

"The C-MOVE allows an application entity to instruct another application entity to
transfer stored SOP Instances to ANOTHER application entity using the C-STORE
operation. <...> The C-STORE sub-operations shall always be accomplished over an
association DIFFERENT from the association which accomplishes the C-MOVE
operation."

Section C.4.3:

"The C-GET operation allows an application entity to instruct another application
entity to transfer stored SOP Instances to the INITIATING application entity
using the C-STORE operation. <...> The C-STORE sub-operations shall be
accomplished on the SAME association as the C-GET operation."

There is also an important note in Part 7, Section 7.5.1.1:

"Note 1 : <...> It is expected that in most environment the C-MOVE is a simpler
solution despite the fact that two associations are required. The use of the
C-GET service may not be widely implemented. <...> It was left in this version of
the Standard for backward compatibility with previous versions of the Standard."

In other words, the use of C-MOVE is highly recommended.

Good luck for your Q/R implementation,

Herve GARFAGNI.

--------------------------------------------------------------------------
Herve GARFAGNI (GE Medical Systems - Europe, Network Products & Services)

--------------------------------------------------------------------------

Walter O. Haas

unread,

Sep 5, 1995, 3:00:00 AM9/5/95

to

In article <42hb59$a...@lilith.uab.es>,
Craig D. von Land <cr...@care2.uab.es> wrote:
>ha...@xmission.xmission.com (Walter O. Haas) wrote:
>>...

>>You can accomplish the function of a C-GET by doing a C-MOVE to
>>yourself, so I consider C-GET to be redundant. I'm pretty sure that
>>I ran into wording in the standard that described it as "deprecated"
>>but I can't find that at the moment. I don't plan to implement C-GET
>>myself.

>I don't think that C-GET is redundant since an AE can implement C-GET
>without having to accept associations from external AE's. If you do a
>C-MOVE to yourself, you have to establish another association, negotiate
>the transfer syntax again, and the AE must support multiple simultaneous
>associations. This can add a lot of overhead for a simple AE that just
>wants to support C-GET.

I'm assuming that an implementation has to support C-STORE anyway.
My implementation has a daemon that listens for associations on port 104
and responds to them. When it gets a C-STORE request it stores the
associated image, etc. If I were to implement C-GET it would have to be
in a user-invoked client program that would then need to have logic to
coordinate its C-STORE operation with the daemon's C-STORE operation.
Since we don't have a full-blown DBMS, this would mean that it would be
necessary to implement coordination between programs instead of just
between forks, a much more complicated requirement.

Before I started into this project I thought as you do. Then I realized
that most of the implementations on the market won't allow a remote host
to do Query/Retrieve, Move or Get; they insist that only they can initiate
the C-STORE request. When you get into it, you see that C-STORE is actually
the simplest thing to support in a minimal implementation which I would
imagine is why it's so common. So given present reality an RTP workstation
(which is what I implemented for) *must* support a C-STORE initiated from
a remote host; anything else is optional.

-- Walt

Craig D. von Land

unread,

Sep 5, 1995, 3:00:00 AM9/5/95

to

ha...@xmission.xmission.com (Walter O. Haas) wrote:
>...
>You can accomplish the function of a C-GET by doing a C-MOVE to
>yourself, so I consider C-GET to be redundant. I'm pretty sure that
>I ran into wording in the standard that described it as "deprecated"
>but I can't find that at the moment. I don't plan to implement C-GET
>myself.
I don't think that C-GET is redundant since an AE can implement C-GET
without having to accept associations from external AE's. If you do a
C-MOVE to yourself, you have to establish another association, negotiate
the transfer syntax again, and the AE must support multiple simultaneous
associations. This can add a lot of overhead for a simple AE that just
wants to support C-GET.

--
Craig D. von Land
Computer Vision Centre
Autonomous University of Barcelona, Spain

Fred Prior

unread,

Sep 6, 1995, 3:00:00 AM9/6/95

to

A key difference that most respondents seem to have missed is the
complex negotiation reqired for C-GET. Because the C-GET and the
C-STORE use the same association but with opposite SCU/SCP roles there
is a very complex extended negotiation required to set up the C-STORE
context within the C-GET context. In my opinion this makes C-MOVE a
far superior tool.

Fred W. Prior, Ph.D.
Chief, Radiologic Computing & Imaging Science
Department of Radiology
PennState College of Medicine
Hershey, PA 17033