C-Move

[Atila Gunes]

Hi,

I'm in a decision point to write C-Move functionality.. I cant imagine
why i want a client send an image from server to another client.. Which
devices need it ? I think modalities dont need it coz they just store
their files to server..

I dont know if we use c-move when an print command is issued.. can you
tell me why do i need C-Move ? It will force my clients listen to a
port and act like a server. it means consuming more resources of client
computers..

I'm planning to use just C-Get.. i need your comments..

Thanks in advance..

Atila Gunes

[herman o.]

don't use C-Get, you can achieve the same functionality with a C-Move
to yourself, and secondly, almost no-other vendor supports C-Get.
A good application for Move is pre-fetching images from an archive to a
workstation by an intelligent router.

Herman O.

[hm.m...@vumc.nl]

It would be very helpfull in doing e.g. a kind of prefetch task from
any workstation to a diagnostic workstation performed by administrative
persons.

Atila Gunes schreef:

[David Clunie]

Hi Atila

The choice has nothing to do with resources consumed;
listening on a port consumes no significant resources.

This is a design/functionality based decision, and like
you say is a matter of "acting like a server" or not.

The popularity of C-Move over C-Get is a consequence of
the fact that almost everybody implements an "ordinary"
C-Store SCP anyway (a port listening for incoming
connections and storing whatever is received and making
it available to the local application), so adding retrieve
capability with a C-Move is/was a near trivial extension.

C-Get on the other hand, requires a little more logic to
"demultiplex" the inbound C-Stores on the same association.

C-Get has the very distinct advantage that it works fine across
firewalls; only a single requester-initiated connection is
required, rather than the additional inbound connection
required by the C-Store association for C-Move (analogous
to passive ftp). This is a functional advantage that cannot
be mimicked with a C-Move.

Another functional advantage is that with C-Get there is no
need to be pre-configured to know the presentation address
(IP and port number) corresponding to the AET to which to
retrieve the objects.

An additional C-Get advantage is that it may be easier to write
a retrieving application to match up what was asked for with
what is received, as opposed to having the objects come in
through another thread or process that is handling the
other association, but that is only an engineering convenience,
not a functional difference.

G-Get has the very distinct disadvantage that one has to know
in advance which SOP Classes need to be negotiated on the
single outbound association for the returning C-Stores to
work, a significant functional disadvantage that requires
either negotiating every known SOP Class in advance (getting
harder since there are a lot, especially when permuted with
the available transfer syntax combinations, and one cannot
always query for the SOP Classes in advance (optional not
mandatory query key), and one cannot assume from the known
modality (original versus enhanced SOP Classes, as well as
presentation states, key object documents, etc)).

It is also a bit harder to code, but that is probably more a
consequence of lack of familiarity with it than any inherent
complexity.

As Herman points out, C-Move is much more commonly implemented
by storage devices than is C-Get; having said that there are
toolkits that implement C-Get, some have been tested with each
other and do work. But for widespread deployment, you might
need to wrap your own C-Get proxy around a PACS that only
implemented C-Move.

There are applications that want to move things around
to places other than themselves, whether you can imagine them or
not, but they are hardly the driving force behind the popularity
of C-Move, which is a consequence of expediency; to some extent
this capability is also limited in practice by the need to pre-
configure everyone's AETs to match presentation addresses, since
nobody bothers to implement network configuration management
(unfortunately).

C-Move and C-Get have nothing to do with print, at least not
with DICOM Basic Print, which has its own messages for setting
the pixel data that do not use composite image transfer (don't
even think about using Stored Print, which is dead and retired).

But if you want to play around with C-Get, it is implemented in
my PixelMed toolkit, Dave Harvey has it in his (MedicalConnections)
and you can test with his public server, OFFIS has it in
their dcmtk; I can't remember whether Mallinckrodt CTN
and Gunter's dcm4che have it or not. A quick Google of PACS vendors'
DICOM Conformance Statements would tell you how widely supported
it is in commercial products, or not, as the case may be.

David