DUL_RequestAssociation in blocking mode

[lisvi]

Hi,

I have just a quick question:

During testing with dcmtk I figured coincidentally out that PRV_NextPDUType(association, DUL_BLOCK, PRV_DEFAULTTIMEOUT, &pduType) called in
DUL_RequestAssociation( DUL_NETWORKKEY ** callerNetworkKey, DUL_ASSOCIATESERVICEPARAMETERS * params, DUL_ASSOCIATIONKEY ** callerAssociation, int activatePDUStorage)
has the blocking mode as default activated. In case of a misconfiguration to a non dicom peer, the application is waiting until data was received from peer....

Is this a desired behavior?

Many thanks in advance!

[takeos]

Recently one of our customers reported that our C-STORE SCU application built on DCMTK (dcmnet) stopped responding while communicating with SCP and my guess was that was because of the blocking behavior you mentioned, so I tried to modify the code to make it nonblocking.

The first thing I did was adding "timeout" parameter to DUL_RequestAssociation() function and pass it to PRV_NextPDUType(). Then I thought it's done but it was not. DUL_RequestAssociation() kept returning unfamiliar error "DUL Finite State Machine Error: No action defined, state 5 event 17" So I had to read DICOM standard carefully, which I do not do usually, and found the table 9-10 in PS 3.8 that explains "ARTIM timer expired" event is not expected to occur on Sta5 "Awaiting A-ASSOCIATE-AC or A-ASSOCIATE-RJ PDU".

According to the document, I modified DUL_RequestAssociation() as below;

Original:

Code: Select all

    cond = PRV_NextPDUType(association, DUL_BLOCK, PRV_DEFAULTTIMEOUT, &pduType);
    if (cond == DUL_NETWORKCLOSED)
        event = TRANS_CONN_CLOSED;
    else if (cond == DUL_READTIMEOUT)
        event = ARTIM_TIMER_EXPIRED;

Modified:

Code: Select all

    cond = PRV_NextPDUType(association, DUL_NOBLOCK, timeout, &pduType);
    if (cond == DUL_NETWORKCLOSED)
        event = TRANS_CONN_CLOSED;
    else if (cond == DUL_READTIMEOUT)
	{
		assert((*association) != NULL);
		assert((*association)->protocolState == STATE5);
		event = TRANS_CONN_CLOSED;
	}

The code has not yet been tested thoroughly but I hope it will be some help for you. I also hope someone will point out anything wrong with my modofication.

Thanks,
takeos

[lisvi]

Hi,

thank you for your helpful reply. As I could understand after reading the section in the DICOM standard as you mentioned, it is not intended by the DICOM standard that peer does not send any data?! So, I would say that the blocking mode is the default behavior?

Maybe some of the other users have a clue about this issue...

Thanks!