boost::asio error for UDP async_receive

问题:

I'm having a problem with a weird error from boost::asio. I am implementing half of a TFTP server (server->client only). I get the first RRQ packet on port 69 on the first socket and then create another socket to carry out the DATA,ACK exchange. I start an async_receive() on that socket and then do a send() of the first packet of data. I then get the handler callback for the receive (I assume the ACK coming in) and it gives the error "No connection could be made because the target machine actively refused it" which I understand from another thread here means ERROR_PORT_UNREACHABLE.

I really don't understand how a receive call can cause an UNREACHABLE error since I am not reaching out to anything, I am receiving. I checked the result of the send() and there is no error there.

I checked the local and remote endpoints in the socket (before and after the error) and they have the correct IP address and port for both.

Any ideas? I've googled around and can't find anyone else having this problem. Most results led me to stackoverflow so I ask here.

EDIT -- My problem was that I was using the debugger. By the time I got around to sending the first data packet, after the client had sent a dozen requests in about a second, the client timed out and gave up and my data was too late. When I run without breakpoints it works fine. Thanks to everyone for the advice. It was watching the packets in Wireshark that gave me the clue.

回答1:

The reason the send succeeds is because the send simply indicates that the packet has been given to the OS. In particular, the OS then sends that packet to the destination, and it responds with an IP packet indicating that the host is not listening. Your OS then receives it, and sets a flag on your socket that causes the next read to fail. Since you're already performing an asynchronous receive, it cause the receive to return the error.

If possible, I would highly recommend using wireshark or something similar to watch the UDP exchange, and see if you can identify any other issue. I'm not familiar with the TFTP protocol, and can't provide much input there.