DcmSCP in multiprocess mode (Windows)

[st80rules]

well like I said, I'm trying to re-implement waitForAssociation(), and need to access almost all the private attributes of the class, just like the DcmSCP::waitForAssociation() method does.

[st80rules]

In trying to get a multi-process framework up and running, I noticed that your own DUL code uses DuplicateHandle() to duplicate the socket handle that is handed down to the forked (CreateProcess()ed) child. But the MSDN documentation says this about DuplicateHandle:

You should not use DuplicateHandle to duplicate handles to the following objects:


- I/O completion ports. No error is returned, but the duplicate handle cannot be used.
- Sockets. No error is returned, but the duplicate handle may not be recognized by Winsock at the target process. Also, using DuplicateHandle interferes with internal reference counting on the underlying object. To duplicate a socket handle, use the WSADuplicateSocket function.

[Michael Onken]

Hi,

is it really necessary for you to re-implement waitForAssociation?

The DuplicateHandle stuff was done by a company that sent us a patch. So far it worked more or less good, however, it is not so easy to have it not leaking memory.

Since it works we did not try WSADuplicateSocket, but i add an item to our todo list to evaluate this, somewhen Or you send us a patch, that may fasten this up. Thanks for the hint to the documentation, anyway!

Best regards,
Michael

[st80rules]

For my needs, yes. I'm implementing a QR SCP node, with an SQL backend, and don't like the approach of CreateProcess() to support multi-processing. In the context of an SQL backend, there are issues like connecting to the database, using prepared statements, etc., that don't really co-exist well with starting a process for every association.

My current implementation uses a "pool" of pre-started processes, and dispatches incoming associations to them. I had to make some modifications to the DcmSCP class, also a bit to the DUL layer, but it works fine so far.

Plus, waitForAssociation is defined as virtual and "overridable" in your API, no?

I'll evaluate using WSADuplicateSocket, but digging further did show that your approach seems to work well, with the exception of the warning about internal reference counting in the MSDN documentation.

[Michael Onken]

Hi,

I understand the problem with your application. I am not sure whether DcmSCP is then perfectly suited for you. You may copy large parts of the code into your own class for now -- I am hesitating make the private members protected but hmm, maybe I have to re-think that.

My original idea is to make it as impossible as possible ( ) to use the class the wrong way by fiddling around with private data and instead to offer a public API that is sufficient to implement all useful functionality.

waitForAssociation is made virtual, right, it was done without too much thinking but just to say "hm, maybe someone wants to overwrite this, so I make it virtual to be safe". However, without access to private data it does not make too much sense except of doing some pre-work for setting up your own variables in the derived class.

Maybe there is an elegant way to solve your problem on the API level? That would be my preferred way to solve this. I was thinking for example in having a public function inside DcmSCP to handle over an existing association and takes over responsibility for it, i.e. answering DIMSE requests. The rest of the parameters could be copied, too, as necessary. takeOverAssociation(DcmSCP* fromThisSCP) for example, or let's call it stealAssociation()

Does the last make sense?

Best regards,
Michael

[st80rules]

Yes that makes sense, but doesn't that already exist with handleAssociation()?

What maybe should be surfaced is a virtual API for starting a multi-process handling. The default would CreateProcess and hand off the socket handle to the new process, but someone else (like me) would work differently.

[feldman_joel]

Has any progress been made with this issue? I am trying to override waitForAssociation, but I can't access m_assoc because it is a private. Same issue with trying to override handleAssociation. I tried making my own waitForAssociation, creating a T_ASC_Association *assoc and calling ASC_receiveAssociation that led to problems later because I needed access to m_assocConfig which is private. I really do not want to go down the CreateProcess path with Windows. Is my best option to modify the current DcmSCP, which I don't want to do either? Any other suggestions?

Thank you

[st80rules]

No everything is in the same state. What I did is modify the DcmSCP class, so I'm stuck with redoing the same changes every time I get a new dcmtk version. I find that subclassing is difficult in dcmtk, in fact I asked a broad question about that 2 weeks ago (and got no answer BTW).

[J. Riesmeier]

Maybe, you find the following commit helpful: "Initial checkin of SCP pool, threaded SCP and related test."
http://git.dcmtk.org/web?p=dcmtk.git;a= ... 855e40453b