Project

General

Profile

Actions

Bug #618

open

Assocation aborted due to network timeout in storescp

Added by Jörg Riesmeier over 10 years ago. Updated over 5 years ago.

Status:
Assigned
Priority:
Normal
Category:
Library
Target version:
-
Start date:
2014-12-10
Due date:
% Done:

80%

Estimated time:
Module:
dcmnet
Operating System:
Compiler:

Description

According to the following forum posting, the receive timeout in the network module can cause problems when it takes too long to send the data, e.g. when the SCU needs to convert huge amounts of pixel data based on the negotiated transfer syntax:

http://forum.dcmtk.org/viewtopic.php?f=1&t=4140

In the above forum posting, the author also asks whether the error code DUL_PEERABORTEDASSOCIATION really is appropriate. He proposes DUL_NETWORKCLOSED (or something like that).

Of course, the timeout value (60 seconds) should be configurable too.


Files

socket_timeout_patch_2.diff (5.71 KB) socket_timeout_patch_2.diff Proposed patch for configurable socket timeout Jörg Riesmeier, 2015-04-08 13:34

Related issues 1 (0 open1 closed)

Related to DCMTK - Bug #524: recv() timeout parameter should be configurable (and the default value should be changed?)ClosedJörg Riesmeier2013-06-14

Actions
Actions #1

Updated by Jörg Riesmeier over 10 years ago

The attached patch has been provided by "Ryan, William J. (Bill)" <> (see his email from 2015-04-01):

We recently ran into a particular device that was keeping an association alive while acquiring more images. Often, the delay between images would last longer than 60 seconds, and the underlying socket would timeout and hang up. I found a post on your forums regarding the DISABLE_SEND_TIMEOUT pre-processor definition which lead me to the right place in the code to solve my problem. Rather than just compiling with this option turned on, we needed a little more control on the duration of the socket’s timeout. So I added some code to allow the user to pass in an explicit value on the command line. I thought this feature may be useful for others that experience the same problem.

I’ve created a patch and attached it here. I really must apologize in advance since I don’t know all of your best practices and coding standards. I just sent a solution that worked for us, and imagine you’ll be able to adapt the code to your standards.

If you need me to take any other steps – such as posting a note to your forum or creating a feature request in some system – please let me know and I’ll do my best to get what you need.

Actions #2

Updated by Jörg Riesmeier over 8 years ago

  • Assignee set to Jörg Riesmeier
Actions #3

Updated by Jörg Riesmeier over 8 years ago

  • Status changed from New to Assigned
  • % Done changed from 0 to 80

With commit 8d73a7f, the send() and recv() timeouts are now configurable at runtime (default is still 60 seconds).

What's still missing is to check whether the error code DUL_PEERABORTEDASSOCIATION is appropriate (see above).

Actions #4

Updated by Jörg Riesmeier over 8 years ago

Further investigations (with "storescp -ts 1" and "dcmsend +dly" trying to send a very large compressed DICOM image that needs to be decompressed for transfer) show...

When the receive timeout elapsed on storescp-side, the output to the logger is:

T: DIMSE receiveCommand
T: DUL  FSM Table: State: 6 Event: 16
T: DUL  Event:  Transport connection closed
T: DUL  Action: AA 4 Indicate AP Abort
I: Association Aborted

On client-side (e.g. dcmsend), the output is:

E: Failed sending C-STORE request: 0006:020e DIMSE Failed to send message
E: 0006:031d TCP I/O Error (Broken pipe) occurred in routine: writeDataPDU
F: cannot send SOP instance: DIMSE Failed to send message
F: 0006:031d TCP I/O Error (Broken pipe) occurred in routine: writeDataPDU
I: Aborting Association
E: Association Abort Failed: 0006:031d TCP I/O Error (Broken pipe) occurred in routine: sendAbortTCP

Actions #5

Updated by Jörg Riesmeier over 8 years ago

After checking the DICOM standard (state machine in Part 8), the implemented state transition (see above) seems to be correct. However, I'm not sure whether the returned DUL_PEERABORTEDASSOCIATION is really appropriate:

/* AA_4_IndicateAPAbort
**
** Purpose:
**      Issue A-P-ABORT indication primitive.
**
** Parameter Dictionary:
**
**      network         Handle to the network environment
**      association     Handle to the Association
**      nextState       The next state to be reached from the current state
**      params          Service parameters describing the Association
**
** Return Values:
** Notes:
**
** Algorithm:
**      Description of the algorithm (optional) and any other notes.
*/

static OFCondition
AA_4_IndicateAPAbort(PRIVATE_NETWORKKEY ** /*network*/,
         PRIVATE_ASSOCIATIONKEY ** association, int nextState, void * /*params*/)
{
    closeTransport(association);
    (*association)->protocolState = nextState;
    return DUL_PEERABORTEDASSOCIATION;
}

There does not seem to be a condition constant for A-P-ABORT... the same condition constant is returned by AA_3_IndicatePeerAborted().

Actions #6

Updated by Marco Eichelberg over 8 years ago

  • Target version changed from 3.6.2 to 3.6.3
Actions #7

Updated by Marco Eichelberg over 7 years ago

  • Target version changed from 3.6.3 to 3.6.6
Actions #8

Updated by Michael Onken over 5 years ago

  • Target version deleted (3.6.6)
Actions

Also available in: Atom PDF