Posts by jsalk

Quote from marcelvanherk

big-endian does not work in conquest - yet (never fixed it and enabled it).
So that may explain. However, it is a k-pacs bug if it does not convert from
little-endian to big-endian on need, because conquest reports it cannot handle
big-endian.

I do not think that ConQuest is the culprit here. The process log indicates
that K-Pacs has negotiated Little Endian Implicit VR transfer syntax
(UID 1.2.840.10008.1.2) with ConQuest. In other words: K-Pacs has agreed
to send the data to ConQuest with Little Endian encoding.
But then K-Pacs simply drops the connection without actually converting and
sending the data if the corresponding files in the imagebox are encoded in
Big Endian TS.

I also think this is a bug in K-Pacs. I'm wondering if anybody else can confirm
this behavior. (I'm running K-Pacs 1.5 & ConQuest 1.4.14 with MySQL on Linux
if that matters.)

Best regards - Juergen

Quote from marcelvanherk

"connection terminated" shows up if the sending application hangs up before transfer is complete. I have seen StoreSCU do this if the image transfer syntax does not correspond with the requested transfer syntax [ ... ]

Hi Marcel,

thanks for your response. I have checked the encoding of the questionable DICOM image files within the K-Pacs
imagebox (i.e. those image files whose transfer from K-Pacs to ConQuest fails). It turned out that these
files are encoded in Big Endian Explicit TS while the other files (i.e. those files whose transfer from K-Pacs to
ConQuest succeed) are encoded in Little Endian.

So it seems that K-Pacs ungently drops the connection to the SCP (here: ConQuest) if the encoding
of the image files in the local imagebox does not correspond to the transfer syntax of the network association
negotiation with the remote storage SCP. I am wondering if this a bug in K-Pacs or if I am missing something
obvious here.

Just for the records: The DCMTK storescu client tool does not seem to have this problem as it happily converts
from Big Endian Explicit to Little Endian Implicit TS before sending the images to ConQuest.

Thanks again.

Juergen

Quote from uril

PACS server Conquest DICOM software 1.4.13 on server side and DCMTK on client side. I have installed DCMTK client on fedora core 7 and have the same problem. "Host 'TON' did not accept the connection". I have turned off firewall on fedora core 7.
What you think should be my next step?

Forgive me for interfering with your discussion, but since you have the DCMTK tools installed on your
client anyway, I would maybe run the command `storescp -v 10004 -od /tmp ´ in a terminal window
on the client side. This invokes a simple SCP for the Storage Service Class on the client side, which
listens on port 10004 for incoming association requests and writes the received files to the /tmp
directory.

Then you can try to connect to this port from the server with `telnet name 10004´ where name
is the hostname of your client. If the connection request already fails at this stage you have definitely
a problem on the networking level, most probably a firewall blocking the port.

Best regards - Juergen

Dear all,

we are in the process of testing the ConQuest DICOM server in our department. The initial idea
was to use K-Pacs as SCU to store all kinds of images that come on CD/DVD from referring
institutions.

However, for a number of image series we keep getting errors when we try to transfer the
images from K-Pacs to ConQuest.

This is the process log from K-Pacs (patient name removed here for privacy reasons):

*******************************************************10.09.2008 15:45:50 ThreadID[828] : Sending images to CONQUESTSRV1 started*******************************************************[828]        >> : c-store request for Series 1.3.12.2.1107.5.2.30.26019.2008072311114414464118643.0.0.0 initiated.[DICOM SCU]        >> : Connected to: 129.129.152.141:5678[DICOM SCU]        >> : Item Type: 2[DICOM SCU]        >> : Association Accept::ReadDynamic[DICOM SCU]        >> : Presentation Context Accept, Transfer Syntax: 1.2.840.10008.1.2[828]        >> : Error: store failed for xxxx yyyy , Study: Schädel_ksb^Routine , Sequence: 0000000003*******************************************************10.09.2008 15:45:51 ThreadID[828] : Closed.Task processed with errors*******************************************************

The ConQuest console shows the following messages (with debug level set to 5):

DGATE (1.4.14, build Wed Sep 10 09:42:26 2008) is running as threaded server
Server command sent using DGATE -- option
Arena 0:
system bytes     =     385024
in use bytes     =     249704
Total (incl. mmap):
system bytes     =    1007616
in use bytes     =     872296
max mmap regions =          2
max mmap bytes   =     622592
Arena 0:
system bytes     =     380928
in use bytes     =     249576
Total (incl. mmap):
system bytes     =    1003520
in use bytes     =     872168
max mmap regions =          2
max mmap bytes   =     622592


UPACS THREAD 0: STARTED AT: Wed Sep 10 15:36:32 2008
*** connection terminated

I could successfully send exactly the same images right out of the Imagebox to
ConQuest by means of the DCMTK storescu tool. So I suspect the problem is
more on the K-Pacs side.

It is also worth mentioning that this problem only occurs for some image series.
The majority of image series can be sent from K-Pacs to ConQuest without any problem.

I would appreciate any idea of what might be going wrong here. Thank you in advance.

Best regards - Juergen

Maybe I am missing the obvious but how would I configure host access control
rules for conquest?

Does conquest provide any provisions to restrict incoming C-Store requests to
certain hosts and to specific peer application entities?

And how would I set up access restriction rules to the Query/Retreive Service Class
that are eventually independently from the access rules for incoming C-Store
requests? I know that there is acrnema.map to restrict retrieve requests
using the C-MOVE message but these restrictions do not seem to apply to queries
using the C-FIND message.

Thank you very much in advance.

Juergen Salk

Hi all,

we are currently in the process of evaluating different options for implementing a
microPACS solution with Q/R functionality for our institute. After going through all
the documentation available for ConQuest I am still wondering what would be the
most robust database backend for a Linux based server. I was able to get the
1.4.13 version running with MySQL on Linux without too much hassle and also
to succeed with some initial Q/R tests by means of findscu/movescu from the OFFIS
DCMTK tools.

By looking at the ConQuest documentation, the MySQL driver seems to be quite
promising in terms of performance but also the least tested and matured on Linux.

Therefore I would highly appreciate any direction from the experts for the
preferable database backend for ConQuest on Linux not only in terms of
performance but also in terms of its robustness, scalability and also in terms of
possible migration to a full featured commercial PACS system in the future.

Thank you very much in advance.

Best regards - Juergen Salk

Paul Scherrer Institute
Center for Proton Radiation Therapy