Welcome Guest! To enable all features, please Login or Register.

Notification

Icon
Error

Options
View
Last Go to last post Unread Go to first unread post
#1 Posted : Wednesday, March 30, 2011 3:07:54 AM(UTC)

v000  
v000

Groups: Registered
Posts: 15


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.
 

Try the latest version of LEADTOOLS for free for 60 days by downloading the evaluation: https://www.leadtools.com/downloads

Wanna join the discussion? Login to your LEADTOOLS Support accountor Register a new forum account.

#2 Posted : Wednesday, March 30, 2011 5:35:30 AM(UTC)

Javed  
Javed

Groups: Registered
Posts: 11


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.
 
#3 Posted : Wednesday, March 30, 2011 10:04:22 AM(UTC)

v000  
v000

Groups: Registered
Posts: 15


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?
 
#4 Posted : Wednesday, March 30, 2011 12:50:59 PM(UTC)

Javed  
Javed

Groups: Registered
Posts: 11


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.
 
#5 Posted : Wednesday, March 30, 2011 9:42:20 PM(UTC)

v000  
v000

Groups: Registered
Posts: 15


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?
 
#6 Posted : Thursday, March 31, 2011 5:14:44 AM(UTC)

Javed  
Javed

Groups: Registered
Posts: 11


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.
 
#7 Posted : Thursday, March 31, 2011 7:58:31 AM(UTC)

v000  
v000

Groups: Registered
Posts: 15


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.
 
#8 Posted : Thursday, March 31, 2011 9:34:56 AM(UTC)

Javed  
Javed

Groups: Registered
Posts: 11


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.
 
#9 Posted : Thursday, March 31, 2011 10:42:36 AM(UTC)

v000  
v000

Groups: Registered
Posts: 15


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.
 
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

Powered by YAF.NET | YAF.NET © 2003-2020, Yet Another Forum.NET
This page was generated in 0.125 seconds.