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
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
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)
c/o Laboratoire SIM | Tel.: (33) 99 33 68 66
Faculte de Medecine | Fax.: (33) 99 33 68 88
Av. du Prof. Leon Bernard | (please mention "Labo SIM")
35000 RENNES |
FRANCE | e-mail: garf...@univ-rennes1.fr
| profs: gar...@mde.gemse.fr
--------------------------------------------------------------------------
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
Computer Vision Centre
Autonomous University of Barcelona, Spain
Fred W. Prior, Ph.D.
Chief, Radiologic Computing & Imaging Science
Department of Radiology
PennState College of Medicine
Hershey, PA 17033