LDicomNet - how to clear the command queue?

Hi,

the documentation states all Send methods of the class are queued for processing and are executed later.

Imagine you queued 3 commands in a row (using Send methods), then in the On callback that was called 1st you have to call a different Send method, and you don't want queued commands to be executed. What would you do?

Thank you.

Please, give us more specifics on what Send methods of LDicomNet and reference to the documentation that talks about “queued for processing”. Typically, if you call SendCFindRequest , you can cancel the request by calling SendCCancelRequest.

In the docs for LDicomNet::OnSend, it says: "When one of the LDicomNet::SendXXX functions is called, the message is not sent immediately. It is placed in a Network queue and sent later. When the data is actually sent, this callback function is called to let the calling AE know that the data has been sent."

So I'm calling SendAssociateRequest() and waiting for OnReceiveAssociateAccept(). Then, depending on the situation, I may call SendReleaseRequest() *directly in the OnReceiveAssociateAccept() callback*.

The problem is, what if between SendAssociateRequest() and SendReleaseRequest() there were other calls to some Send methods (i.e. SendNActionRequest queued, but not sent)? How do I dequeue them?

LEADTOOLS internally maintains and does message synchronization. It creates the PDU packets and sends them over the TCP/IP and OnSend callback is a way to inform user about any potential problem in communication. You can always abort a connection by calling LDicomNet::SendAbort but we prefer closing a DICOM Association using the LDicomNet::SendReleaseRequest.
Also, most DICOM servers in the market place do not have support for asynchronous operations. So, in most cases you will have only one message command in the queue.

Ok, so what you are saying is this code should not emit C-GET and C-MOVE commands:

HiLevelFunc()
{
LDicomNet::SendAssociateRequest()
LDicomNet::SendCFindRequest()
LDicomNet::SendCGetResponse()
LDicomNet::SendCMoveRequest()
}

LDicomNet::OnReceiveCFindResponse()
{
LDicomNet::SendReleaseRequest()
}

This is good news for me. However, I do not get how "in most cases you will have only one message command in the queue" is possible in the above code. Could you please elaborate? Is there a wait condition somewhere in every Send method?

SCU must establish an association before rendering any services from SCP. Once an SCU calls LDicomNet::SendAssociateRequest, SCP may accept or reject the request.
LDicomNet::OnReceiveAssociateAccept or the LDicomNet::OnReceiveAssociateReject event will fire depending on acceptance or rejection by SCP. If LDicomNet::OnReceiveAssociateAccept is called, then SCU can consider that DICOM Associate Connection has been established.
In Associate Request call, SCU can request for AsyncOperations support but it is up to the SCP to accept it or not. SCU can use the LDicomAssociate::IsAsyncOperations function to determine whether asynchronous operations are supported by the established Association.
If a DICOM Associate connection does not support Asynchronous Operations, then an Application Entity must wait for the response from one message before sending another. If Asynchronous Operations are supported, multiple messages may be sent without waiting for a response (note: The number of messages that may be sent is set using LDicomAssociate::SetAsyncOperations).
In this case, multiple message commands queuing up is limited to asynchronous operation with exception of cancellation of the service (C-CANCEL-* request). Again, SCU can always send LDicomNet::SendCCancelRequest to cancel any outstanding service request at any time.

I think I'm beginning to grasp the API logic. Please correct me if I'm wrong:

- command queue size equals LDicomAssociate::GetInvokedOperations()
- LDicomNet::SendReleaseRequest() cancels out one LDicomNet::SendAssociateRequest() in the queue
- LDicomNet::SendCCancelRequest() cancels out one C-xxx-REQ in the queue
- there's no LDicomNet::SendNCancelRequest() to cancel out any N-xxx-REQ

Thank you.

The “Network Queue” mentioned in the OnSend documentation is basically an internal TCP/IP packet buffering queue for our SDK and should not be confused with DICOM commands (e.g. during asynchronous operations) that are pending responses from server (e.g. server side message processing queue).

An example LEADTOOLS “Network Queue” is when sending a 10MB image to a server, toolkit needs build multiple TCP/IP packets depending on the agreed upon PDU max length and TCP/IP buffer size. Each time a packet is sent, OnSend is called with PDU_DATA_TRANSFER as message type to notify the user. Not much a developer can do with our internal queue other then using it for status update or logging.

+++
command queue size equals LDicomAssociate::GetInvokedOperations()
===
Please, see the explanation above.

+++
LDicomNet::SendReleaseRequest() cancels out one LDicomNet::SendAssociateRequest() in the queue
===
LDicomNet::SendReleaseRequest() does not cancel LDicomNet::SendAssociateRequest().
SendReleaseRequest only notifies the SCP that SCU would like to close the already
established association. One should not send release request if there is no established association.

+++
LDicomNet::SendCCancelRequest() cancels out one C-xxx-REQ in the queue
===
This notifies the SCP that SCU would like to cancel the pending service request.
SCP may not stop the process immediately.

+++
there's no LDicomNet::SendNCancelRequest() to cancel out any N-xxx-REQ
===
N-XXX messages are normalized messages and there is no cancel option in the standard.

Hmm... So the right path for me would be creating a queue of my own for all of the Send methods and Connect(). Only then it'll be possible to do what I have in mind.

Thank you again for exhaustive info. Consider my questions answered and topic closed.