Very slow association with invalid adresses - Need to use custom timeout during connecting

[qarmin]

Because this can be implemented, I am changing the discussion in the issue to make it more visible

Discussed in #480

^{Originally posted by qarmin March 19, 2024}
I have this code

    debug!("Establishing association with '{}'...", &addr);
    let mut scu_opt = ClientAssociationOptions::new()
        .with_abstract_syntax(abstract_syntax)
        .called_ae_title(aetitle)
        .max_pdu_length(max_pdu_length);

    if !station_name.is_empty() {
        scu_opt = scu_opt.calling_ae_title(station_name);
    }

    let scu = scu_opt
        .establish_with(addr)
        .map_err(|_e| DicomError::CommonError(format!("Failed to establish connection with {addr}")))?;

    debug!("Association established");
    Ok(scu)
}

and after trying to connect to invalid address, after 2 minutes I have info, that dicom failed to establish connection.
Can this be speed up?
Can I use any workaround?

11:29:01.681 [DEBUG] Establishing association with '192.168.10.124:4242'...
11:31:16.409 [ERROR] Failed to get patients from worklist: Failed to establish connection with 192.168.10.124:4242

[naterichman]

Hi @qarmin can you see if #530 fixed your issue? You should be able to now do

    debug!("Establishing association with '{}'...", &addr);
    let mut scu_opt = ClientAssociationOptions::new()
        .with_abstract_syntax(abstract_syntax)
        .called_ae_title(aetitle)
        .read_timeout(20)
        .max_pdu_length(max_pdu_length);

By setting this, when you call establish it should return with an error after 20s.

[jmlaka]

I tested some code and this does not fix the issue.
The read/write timeout modifies an already established connection.

In case of a network error or faulty IP address is provided the TcpStream::connect will hang.

We need to add another "connection timeout" variable and use TcpStream::connect_timeout instead.

[Enet4]

@jmlaka @qarmin Could you validate that #569 and #570 resolves this issue?

[qarmin]

I tested version 0.8.0 and still I have exactly same problem.
I set timeout duration to 1 second

Code to test

use dicom::core::chrono::Local;
use dicom::dictionary_std::uids::VERIFICATION;
use dicom::ul::ClientAssociationOptions;

fn main() {
    let scu_init = ClientAssociationOptions::new()
        .with_abstract_syntax(VERIFICATION)
        .calling_ae_title("RANDOM")
        .read_timeout(std::time::Duration::from_secs(1));

    println!("BEFORE, current time is: {}", Local::now().format("%H:%M:%S"));
    let _res = scu_init.establish_with("RANDOM@167.167.167.167:11111");
    println!("AFTER, current time is: {}", Local::now().format("%H:%M:%S"));
}

Output

BEFORE, current time is: 15:20:10
AFTER, current time is: 15:22:24

[qarmin]

Well, I was wrong and this is fixed now, because I found that connection_timeout should be used instead read_timeout

        .read_timeout(std::time::Duration::from_secs(1))
        .connection_timeout(std::time::Duration::from_secs(1))
        .write_timeout(std::time::Duration::from_secs(1))

[naterichman]

Hey @qarmin. I was going to say that. I think without that being set it might be platform dependent what that timeout is. For me, I get about 500ms and a "Host Unreachable" Error result. That being said, I realized we don't have any tests for the connection timeout, so I'm working on that now