DICOM @ OFFIS

Discussion Forum for OFFIS DICOM Tools - For registration, send email with desired user name to the OFFIS DICOM team
It is currently Sat, 2018-01-20, 06:10

All times are UTC + 1 hour




Post new topic Reply to topic  [ 9 posts ] 
Author Message
PostPosted: Thu, 2018-01-04, 18:49 
Offline

Joined: Tue, 2017-11-21, 17:47
Posts: 7
Hi all,

I am experiencing a difficult issue that I can't really explain.
I work on a software solution (several executables) and two of them exchange DICOM data through DCMTK.
The emiter is a standalone executable and the receiver is a SYSTEM process launched by one daemon of our own.
The emission / reception process works perfectly fine the way these two entities are.

But for some business reasons we have to turn the receiver into a USER process.
So I made the changes to switch the process type, nothing to do with the DCMTK protocol at all.
And no change at all on the emiter side by the way.

The fact is that now the emiter hangs on the sending of DICOM data.
More precisely it enters the ASC_requestAssociation() function and never gets out...
Which I find really weird because either the request association fails, and then the execution exits right away from the function and resumes normaly, or the connection is established the data is then transmitted and the execution resumes too.

But the ASC_requestAssociation() is not supposed to hang like that. Because, as it is specified, it is asynchronous...

So basically I'm stuck here and I wanted to know if some of you have ever encountered similar hang with this function and what would be the reasons for that ?

Thanks in advance.


Top
 Profile  
 
PostPosted: Fri, 2018-01-05, 11:05 
Offline
OFFIS DICOM Team
OFFIS DICOM Team

Joined: Mon, 2014-03-03, 09:51
Posts: 228
Location: Oldenburg, Germany
The one thing that comes to my mind would be that the port the receiver process is supposed to listen on is a priviliged port and cannot be listened on by user process. This would of course be operating system and configuration specific.


Top
 Profile  
 
PostPosted: Fri, 2018-01-05, 18:21 
Offline

Joined: Tue, 2017-11-21, 17:47
Posts: 7
Actually I took a look a bit closer of the primitives I use to create the receiver and I found some interesting info.
The OS our software solution works on is Windows:

- Without my changes the receiver is created with the ::OpenService() primitve that creates a Windows Service (in this case User Name process is SYSTEM).
- With my changes the receiver is created as a QProcess and launched with the QProcess::startDetached() primitive (in this case User Name of the process is $MYUSERNAME).

I looked up the QProcess documentation and I read that some Windows commands weren't supported with this way to start processes: http://doc.qt.io/qt-5/qprocess.html

I'm currently investigating on the limitations of QProcess, but it may be likely that DCMTK uses some Windows primitives that QProcess do not allow. Actually that won't be surprising to establish a TCP network connection...

So, in the end, I think the question I'm really trying to find some answers is: Does any limitation exist to use DCMTK through a process launched by QProcess ?


Top
 Profile  
 
PostPosted: Fri, 2018-01-05, 18:23 
Offline
DCMTK Developer

Joined: Fri, 2004-11-05, 13:47
Posts: 1661
Location: Oldenburg, Germany
Do you use storescp as the receiver? If so, can you try running it with --single-process?


Top
 Profile  
 
PostPosted: Mon, 2018-01-08, 09:36 
Offline
OFFIS DICOM Team
OFFIS DICOM Team

Joined: Mon, 2014-03-03, 09:51
Posts: 228
Location: Oldenburg, Germany
You don't mean this section, right?
http://doc.qt.io/qt-5/qprocess.html#notes-for-windows-users wrote:
Some Windows commands (for example, dir) are not provided by separate applications, but by the command interpreter itself. If you attempt to use QProcess to execute these commands directly, it won't work. One possible solution is to execute the command interpreter itself (cmd.exe on some Windows systems), and ask the interpreter to execute the desired command.

In case you did, this is about shell commands and not API functions, can't really be the reason for the issue unless you are trying to launch the DCMTK executable without using the full path to its binary... Btw: if you are building a QT application, why don't you simply include DCMTK on library level instead of spawning a process?


Top
 Profile  
 
PostPosted: Mon, 2018-01-08, 11:41 
Offline

Joined: Tue, 2017-11-21, 17:47
Posts: 7
@Michael Onken: We do not use the storescp application but a code of our own inspired from the storescp example (file dcmtk/dcmnet/apps/storescp.cc)
@Jan Schlamelcher: I meant this section indeed, but also this one:
Quote:
On Windows, QProcess uses the Win32 API function CreateProcess to start child processes. While QProcess provides a comfortable way to start processes without worrying about platform details, it is in some cases desirable to fine-tune the parameters that are passed to CreateProcess. This is done by defining a CreateProcessArgumentModifier function and passing it to setCreateProcessArgumentsModifier.

Because I wonder whether some specific arguments need to be passed when process is created, before it is launched, to have it work properly in case of network communications...


Top
 Profile  
 
PostPosted: Tue, 2018-01-09, 17:38 
Offline

Joined: Tue, 2017-11-21, 17:47
Posts: 7
I pushed my investigation a bit further : I compiled dcmtk in debug with pdb files and followed execution into it to see where the code hangs.
Actually it hangs on a call to recv() function of the Winsock API, in the DcmTCPConnection::read() method.

And, again, when the receiver is launched as a SYSTEM process (Windows service) or as a USER process (but not through QProcess) it doesnt' hang.


Top
 Profile  
 
PostPosted: Wed, 2018-01-10, 16:43 
Offline

Joined: Tue, 2017-11-21, 17:47
Posts: 7
The Tcp port I used between the sender and the receiver was also used elsewhere.
I did change that. Now everything works just fine.
Problem solved.


Top
 Profile  
 
PostPosted: Wed, 2018-01-10, 17:48 
Offline
OFFIS DICOM Team
OFFIS DICOM Team

Joined: Mon, 2014-03-03, 09:51
Posts: 228
Location: Oldenburg, Germany
So it was simply a coincendence that it worked unless launched via QProcess? That's a nice error, totally not difficult to identify :o.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 9 posts ] 

All times are UTC + 1 hour


Who is online

Users browsing this forum: Bing [Bot], Google [Bot] and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group