Use of recv() Winsock function within a QProcess ?

[Walibi 33]

Hi All,

I'm experiencing a real issue with the QProcess class along with the use recv() function of the Winsock API.
I work on a software solution, among this software solution there are:
- One executable that sends some DICOM images through TCP (DICOM is basically an API for medical imaging and communication). This is the sender.
- One daemon that launches a Windows Service that receives the DICOM images from the sender. This is the receiver.

This mechanism works actually really well.
But for some business reasons we have to turn the receiver into a user process instead of a system process (Windows service).
So now the daemon launches the receiver through a QProcess instance instead.
The problem is that now the emision of the data makes the sender hangs on a call to the recv() function...
Another problem is that this call is done within the DCMTK library (handles the DICOM emision / reception) and I can't really change that code.

So I guess my question is: is there some kind of restriction to use some Winsock API function within a QProcess ?

[mrjj]

@Walibi-33
Hi, QProcess just starts whatever you ask. there is no restrictions from QProcess side.
However windows have session isolation and other features what might affect it running.

[Walibi 33]

@mrjj Ok, so do you have any idea why the receiver would work just fine when implemented through a Windows Service, but not when implemented using the QProcess class ?
Besides, if I launch the receiver manually (as a user process, so exactly as it was launched with QProcess) it works fine too...
It hangs only when it is launched through a QProcess.

[JonB]

@Walibi-33
It probably comes down to exactly what you're doing.

For example, "One daemon that launches a Windows Service" doesn't sound right, Windows Services are "daemons", you wouldn't launch one from a daemon. Or "the sender hangs on a call to the recv() function", that's possible but are you sure your sender is hanging on receive not send?

The way you describe it:

• When your daemon launches QProcess, that process will inherit your daemon's permissions.
• If your daemon somehow "launches a Windows Service" as you say, that service process will run with permissions as per your Windows Service settings for it.

Hanging on a recv() sounds like there's noting being sent from the send end, you should be able to debug both sides of the socket?

One thought: Are you perchance relying on inheriting sockets across processes? Does your program where you create the QProcess in any shape or form open the sockets and assume they get passed on to the subprocess spawned?

[Walibi 33]

@JonB Hi Jon, thanks for your answer. I'll try to answer all of your questions:

• The recv hangs but on the sender side.
• Yes, I can debug on both sides: sender and receiver. The sender hangs on recv() call when emision of data is launched. But the receiver works fine, it just doesn't never receive anything from the sender.
  => The way I understand it the sender hangs on recv() function because it first try to open the communcation channel with the receiver, but never gets any acknowledgment from it. What makes me think that is that the recv() call where the hangs occurs is within the method ASC_requestAssociation() of the DCMTK library. I actually build this library in debug to get to see what was happening inside of it.
• The Windows Service is launched through a daemon because the daemon actually manages the Windows Service. In case it is accidentally shut down the daemon manager will relaunch the Windows Service...
• The sockets are opened in the QProcess, not before.

I'm wondering if there are some kind of permissions associated to my QProcess that wouldn't allows any network communication ?

[JonB]

@Walibi-33

I'm wondering if there are some kind of permissions associated to my QProcess that wouldn't allows any network communication ?

I doubt it. At the end of the day, QProcess will only be a wrapper around Windows CreateProcess() system call, whose documentation you should read (e.g. https://msdn.microsoft.com/en-us/library/windows/desktop/ms682425(v=vs.85).aspx) in the light of whatever you might need for your stuff to work.

Presumably, you could try doing some of the recv() in the calling process instead of the QProcess subprocess, temporarily? The you could establish whether the problem is in the parent rather than the child?

P.S.
I still don't totally get the relationship between your process(es) & Windows Service. Windows Services have issues about network communication. If you are running stuff out of a Service which requires network access, you need to look at the account you are running that service as?

[Walibi 33]

I finally caught the reason why this wasn't working : The Tcp port set for the communication between the receiver and the sender was also used elsewhere.
I changed that and now everything works just fine.
Anyway, thanks for the help !

[JonB]

@Walibi-33
So how did that make behaviour differ between whether you spawned a QProcess or not?

[aha_1980]

Hi @Walibi-33,

Glad you found a solution - thanks for sharing! So please mark this thread as solved.