C-Echo OnResponseReceived

[David Wetelainen]

While implementing a C-Echo request everything works as planned when the response is a success. However, when the Remote AE rejects the association, the OnResponseReceived does not capture the event. The only way I know the association was rejected is by looking in the logs. (I'm using FO version 2.0.2)

2016-12-02 12:05:12.5556|INFO|Dicom.Network|PACSARCH <- Association reject [result: Permanent; source: ServiceUser; reason: CallingAENotRecognized]

2016-12-02 12:05:12.5868|ERROR|Dicom.Network|Exception processing PDU: {0}

2016-12-02 12:05:12.5868|ERROR|Dicom.Network|Connection closed with error: {0}

Here is my relevant code: (Sorry for the VB.net)

Dim cEcho = New DicomCEchoRequest() With { _

                .OnResponseReceived = AddressOf returnedEcho}

 Dim cEchoClient = New Dicom.Network.DicomClient()

 With cEchoClient

         .Options = New DicomServiceOptions()

                With .Options

                    .TcpNoDelay = False

                End With

           .Linger = 200

            .NegotiateAsyncOps()

End With

 cEchoClient.AddRequest(cEcho)

cEchoClient.Send(sRemoteIP, sRemotePort, False, sLocalAE, sRemoteAE)

 Private Sub returnedEcho(request As DicomCEchoRequest, response As DicomCEchoResponse)

       Console.WriteLine("Returned Status " & response.Status.Description)

       MessageBox.Show("Result: " & response.Description,

                   "Dicom Verify", MessageBoxButtons.OK, MessageBoxIcon.Information) 

 End Sub

Also, can anyone comment on the correct usage of the DicomClient options. Like "Linger" and "TcpNoDelay".

Thanks for any insight.... 

DW

[petr....@gmail.com]

Hi David,

this behavior is correct as there was not echo request sent yet. Firstly client needs to create TCP connection, then negotiate DICOM connection (association) and then DICOM request is being sent. Here all ended at association stage where you "requseted" to connect with different AE Title (reason: CallingAENotRecognized). Your confusion might be caused by fact that all is encapsulated in one final function call (cEchoClient.Send) that do all the magic behind.

Regards,
Petr

[David Wetelainen]

Hi Petr

Your logic makes sense as the C-Echo response needs an open association to respond to a request. However it's not very useful to an end user if the Association is rejected and the user has no way of knowing without digging through logs. So I tried to capture the exception:

Try

cEchoClient.Send(sRemoteIP, sRemotePort, False, sLocalAE, sRemoteAE)

Catch assocRejected As DicomAssociationRejectedException

Console.WriteLine(" Verify Failed " & assocRejected.RejectResult.ToString)

Catch sEx As SocketException

Console.WriteLine(" Network Error "........

End Try

But this didn't work either.. Only the SocketException was captured when I used an invalid IP address.

I guess it's not a show stopper but I like to give the users of my applications useful feedback.

Thanks for your help.

DW

[petr....@gmail.com]

Hi David,

sorry, but this looks to me OK as well, as at this example there was try for acquiring TCP communication as underlying communication channel and then (if successfully setup) Association negotiations would take place.

Regards,
Petr