UdpSocket::recv_from always getting "Resource temporarily unavailable" Error

help
1

I'm trying to read latency between my device and a remote socket address buy computing STUN round-trip time. However I keep getting

e = Os {
    code: 11,
    kind: WouldBlock,
    message: "Resource temporarily unavailable",
}

error here: Cargo.toml · GitHub

What could be causing this?

2

Because you made it a nonblocking socket. Nonblocking recv doesn't block/wait next packet if it's not arrived yet. If you want blocking recv remove .set_nonblocking(true) line.

3

It's taking a really long time for a stun packet to come back, the latency shouldn't be that bad, should it? Or maybe my example stun servers are bad? I've tried other IPs too.

4

Oh I missed that you're doing it in loop with sleep. Sorry.

It is that you're binding 2 UDP sockets with "0.0.0.0:0" address. :0 means to ask OS to give whatever port that is currently unused. So those 2 sockets are bound on different local port. STUN response is sent to the port where its corresponding request is sent from.

5

I updated the code but the recv_from still takes forever.

6

The server likely isn't responding to your message.

7

I spun up a local STUN server and ran your code, and it got further but there were a couple other problems in your code

tokio::task::spawn(async move {
    while let Ok(latency) = result_rx.try_recv() {
        println!("Current latency: {:?}", latency);
    }
});

This future will exit as soon as there isn't a result available immediately. You can just await on recv to receive the next message when it's available.

tokio::task::spawn(async move {
    while let Some(latency) = result_rx.recv().await {
        println!("Current latency: {:?}", latency);
    }
});

You're also using std's UdpSocket, which blocks when waiting for sends or receives. Since you're using join on your send and receive futures, this results in the reader blocking the sender. Using tokio's UDP socket and adding some awaits allows the program to run to completion instead of getting stuck after the first message. Using std's might work with the nonblocking mode, but it might just be easier to use tokio's socket anyway.

1 Like
8

I have updated the code accordingly. Now I have to find publicly available and free to use STUN servers that are always online. Thank you.

9

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.