send_to doesn't work on the Windows

[Covertness]

I find UdpSocket::send_to return Ok(None) on the Windows, but the client don't receive any response. The code:

fn transmit_handler(tx_recv: RxQueue, tx_only: UdpSocket) {
    loop {
        match tx_recv.recv() {
            Ok(q_res) => {
                match q_res.response.to_bytes() {
                    Ok(bytes) => {
                        let _ = tx_only.send_to(&bytes[..], &q_res.address);
                    },
                    Err(_) => {
                        error!("Failed to decode response");
                    }
                }
            },
            Err(_) => {
                info!("Shutting down Transmit Handler");
                break;
            }
        }
    }
}

[alexcrichton]

@Covertness do you have a larger code sample that we could test out and run? It looks like errors may be ignored here which may be indicative of a problem?

[Covertness]

@alexcrichton Yeah. I met this issue when I test the coap-rs. The project is A Constrained Application Protocol(CoAP) library. You can run examples or test cases to reproduce this issue.

[alexcrichton]

@Covertness ah my point was that on this line the result is ignored, so it could perhaps be sending "would block" which is why it's not transmitting. This may work on Unix for now due to slightly different semantics, and if that error is handled it may work correctly on Windows.

[Covertness]

@alexcrichton The result was Ok(None) when I tested it on Windows. It doesn't seem like an error.

[alexcrichton]

@Covertness Ok(None) indicates that it wasn't able to complete the request, it needs to wait until a readable event happens for the socket

[jamesmunns]

@alexchrichton are we misusing the UDP socket in some way here? From a high level, we have two threads that have access to the UDPSocket (one has the original, one has a clone): One that is recv()ing, which dispatches the incoming messages to a threadpool, and a second thread that send()s, if the threadpool workers have a response (these responses are managed through a channel to the tx-thread).

Is the Ok(None) an indicator of an issue with how we use the library, or is it some kind of other issue?

[alexcrichton]

@jamesmunns I haven't scrutinized the code in too much detail, but Ok(None) indicates that nothing was sent along the socket and it needs to be deferred to a later point somehow. The precise semantics of when I/O succeeds for fails are subtly different on Unix and Windows, but the contracts are the same.

[Covertness]

@jamesmunns It seems that we can send the response only when a readable event happen. I will have a try.

[jamesmunns]

@Covertness You could just give the TX thread a handle to the write side of the channel, which will just put it back in the queue to be consumed later.

[alexcrichton]

It sounds like this was a local problem, so I'm going to close, but I'd be willing to help out if there are still problems!