Connection refused when using a UDP socket inside a loop - c++

Question

Consider the following MWE class foo, which has a send member function that allows sending strings to the loopback address on port 1337 over UDP:
Header file: foo.h
#include <boost/asio.hpp>
class foo
{
public:
foo(); // Constructor.
void send(std::string const& message);
private:
boost::asio::io_service ios;
boost::asio::ip::udp::socket sock;
boost::asio::ip::udp::endpoint endp;
};
Implementation file: foo.cc
#include "foo.h"
foo::foo() : sock{ios}, endp{boost::asio::ip::address::from_string("127.0.0.1"), 1337}
{
sock.connect(endp);
}
void foo::send(std::string const& message)
{
sock.send(boost::asio::buffer(message));
}
Now I want to use the foo class to send the string Hello, World!\n to myself. So in the main function I instatiate a foo object and then I call foo.send() 5 times (waiting 1 second between bursts) using a for loop.
Main function:
#include "foo.h"
#include <iostream>
#include <chrono>
#include <thread>
int main(int argc, char* argv[])
{
foo foo;
for(int i = 0; i<5; i++)
{
foo.send("Hello, World!\n");
std::cout << i << std::endl;
std::this_thread::sleep_for(std::chrono::milliseconds(1000));
}
std::cout << "Done" << std::endl;
return 0;
}
The code compiles successfully. However, at runtime the program crashes and throws the following error:
terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::system::system_error> >'
what(): send: Connection refused
Aborted (`core' dumped)
The Connection refused error message is very confusing since UDP is connectionless by design. So the program should send 5 UDP messages whether the recipient is listening or not.
What am I doing wrong here?

Answer 1

UDP is connectionless by design. So the program should send 5 UDP messages whether the recipient is listening or not.
The first does not imply the second. With UDP, error reporting is not guaranteed, which is quite different from a guarantee of no error reporting. Typically, a packet arriving on a port where there is no listener will trigger an ICMP Port Unreachable message back to the sender, and most implementations of the Sockets API will report that to the application on the next attempt to transmit to the same destination. With loopback, detecting an error is even easier for the network stack.