Fail more quickly when creating an association to an invalid server

[medihack]

When creating a new association to an invalid PACS server (e.g. PACS is down) I want it to fail more quickly. It currently hangs for about 30 seconds. Is there a timeout parameter to adjust for that (network_timeout, dimse_timeout or acse_timeout don't seem to have an effect on this)?

How can I force the faulty association to fail more quickly? [pynetdicom 1.5.3]

EDIT:
I investigated a bit further. The problem is that after the ACSE timeout the association is aborted which then hangs because the kill takes so long. I wonder if this is really necessary as the association was never established in the first place.

[scaramallion]

It shouldn't take much longer than the ACSE timeout. Is there anything listening on the IP/port and you're not getting a response, or is there nothing there to connect to?

For me, with python -m pynetdicom echoscu localhost 11112 -d with nothing listening on that port the association fails immediately (note that I've included the FSM debugging handler output):

I: Requesting Association
E: Association request failed: unable to connect to remote
E: TCP Initialisation Error: Connection refused
R: Sta1 + Evt1 -> AE-1 -> Sta4
R: Sta4 + Evt17 -> AA-4 -> Sta1
E: Association Aborted

The abort mentioned here is actually an A-P-ABORT which is sent to the local user rather than the peer. This is required by the DICOM state machine (its AA-4 in the above output).

If I start a socket listening on 11112 (and not responding) then the association fails after the acse_timeout value (echoscu app with -ta 5 means this is ~5 seconds):

I: Requesting Association
R: Sta1 + Evt1 -> AE-1 -> Sta4
D: Request Parameters:
D: ======================= OUTGOING A-ASSOCIATE-RQ PDU ========================
D: Our Implementation Class UID:      1.2.826.0.1.3680043.9.3811.2.0.0
D: Our Implementation Version Name:   PYNETDICOM_200
D: Application Context Name:    1.2.840.10008.3.1.1.1
D: Calling Application Name:    ECHOSCU         
D: Called Application Name:     ANY-SCP         
D: Our Max PDU Receive Size:    16382
D: Presentation Context:
D:   Context ID:        1 (Proposed)
D:     Abstract Syntax: =Verification SOP Class
D:     Proposed SCP/SCU Role: Default
D:     Proposed Transfer Syntaxes:
D:       =Explicit VR Little Endian
D:       =Implicit VR Little Endian
D:       =Deflated Explicit VR Little Endian
D:       =Explicit VR Big Endian
D: Requested Extended Negotiation: None
D: Requested Common Extended Negotiation: None
D: Requested Asynchronous Operations Window Negotiation: None
D: Requested User Identity Negotiation: None
D: ========================== END A-ASSOCIATE-RQ PDU ==========================
R: Sta4 + Evt2 -> AE-2 -> Sta5
E: ACSE timeout reached while waiting for response to association request
I: Aborting Association
D: Abort Parameters:
D: =========================== OUTGOING A-ABORT PDU ===========================
D: Abort Source: DUL service-user
D: Abort Reason: No reason given
D: ============================= END A-ABORT PDU ==============================
R: Sta5 + Evt15 -> AA-1 -> Sta13
R: Sta13 + Evt17 -> AR-5 -> Sta1

This abort is an actual A-ABORT sent to the peer (AA-1). From the output we wait until the connection is closed (Evt17) before dropping back to Sta1, which in pynetdicom indicates the end of the Association thread. The connection should get closed quickly by pynetdicom as there's a check for Sta13 in the DUL reactor which closes the socket (and emits Evt17) if there's no incoming data.

Both cases are very quick for me, could you provide more details on your system or maybe a reproducible example?

[medihack]

Hi @scaramallion, thanks for your help! I really appreciate what you do for this project. If you put up a sponsors link for pynetdicom, I would be happy to sponsor it a bit (and maybe others will follow). This is such an important infrastructure project, especially for building a full pipeline with all this machine-learning python stuff.

That said, regarding the timeout problem, it hangs with Aborting the association much longer than any timeout set when trying to connect to a nonexistent server IP.

from pynetdicom import AE, debug_logger
from pynetdicom.sop_class import (
    PatientRootQueryRetrieveInformationModelFind,
)

debug_logger()

ae = AE(ae_title="ADIT")
ae.add_requested_context(PatientRootQueryRetrieveInformationModelFind)
ae.acse_timeout = 3
ae.dimse_timeout = 3
ae.network_timeout = 3

assoc = ae.associate("169.42.95.87", 104) # IP does not exist in the network
assoc.release()

I: Requesting Association
E: ACSE timeout reached while waiting for response to association request # <- Correct timeout after 3 seconds
I: Aborting Association # <- Here it hangs
E: Association request failed: unable to connect to remote
E: TCP Initialisation Error: Connection refused

[scaramallion]

OK, I can reproduce with an invalid IP, I'll look at a fix and do a patch release when done.