Recent changes to feature-requests

#22 Add timeout to receive_from().

2024-09-07T11:08:54.067000Z

I have done a bit of digging into the code.

It seems that what is needed is to add a check for a timeout in socket_ops.ipp, functions sync_recv, sync_recvfrom, sync_recvmsg.

Instead of having something like

  for (;;)
  {
    // Try to complete the operation without blocking.
    signed_size_type bytes = socket_ops::recv(s, bufs, count, flags, ec);

    // Check if operation succeeded.
    if (bytes > 0)
      return bytes;

    // Check for EOF.
    if ((state & stream_oriented) && bytes == 0)
    {
      ec = asio::error::eof;
      return 0;
    }

    // Operation failed.
    if ((state & user_set_non_blocking)
        || (ec != asio::error::would_block
          && ec != asio::error::try_again))
      return 0;

    // Wait for socket to become ready.
    if (socket_ops::poll_read(s, 0, ec) < 0)
      return 0;
  }

have something like

setsockopt(s, SOL_SOCKET, SO_RCVTIMEO,(struct timeval *)&tv,sizeof(struct timeval));
auto starttime = now();
while ((now()-starttime) < timeout)
  {
    // Try to complete the operation without blocking.
    signed_size_type bytes = socket_ops::recv(s, bufs, count, flags, ec);

    // Check if operation succeeded.
    if (bytes > 0)
      return bytes;

    // Check for EOF.
    if ((state & stream_oriented) && bytes == 0)
    {
      ec = asio::error::eof;
      return 0;
    }

    // Operation failed.
    if ((state & user_set_non_blocking)
        || (ec != asio::error::would_block
          && ec != asio::error::try_again))
      return 0;

    // Wait for socket to become ready.
    if (socket_ops::poll_read(s, 0, ec) < 0)
      return 0;
  }

The socket option would guarantee that the loop would check condition at least once.

#21 Configure flags while creating sockets.

2024-09-07T10:59:23.786000Z

That is a great idea.

Add timeout to receive_from().

2024-09-06T00:28:51.078000Z

Hello,

The default example for the synchronous UDP datetime server has a chance to lock indefinitely if a datagram never arrives. Since UDP is inherently unreliable, this is not a "rare unexpected exotic obscurity", it's one of the reasons why UDP might be used.

This problems is not present for TCP, since TCP has built-in failure mechanisms when a "connection" breaks. But an UDP socket doesn't have to be "connected" even in a limited UDP sense.

I would like to ask that a timeout argument is added to the "receive_from" procedure.

The same effect can be achieved using:

      {
      std::thread t([&]() { io_context.run(); });
      t.detach();
      auto recv_length = socket.async_receive_from(
          boost::asio::buffer(recv_buf), sender_endpoint, 0,
                                                   boost::asio::use_future);

      if (recv_length.wait_for(std::chrono::seconds(5)) != std::future_status::timeout) {
        std::cout.write(recv_buf.data(), recv_length.get());
      }}

However , this requires switching from "receive_from" to "async_receive_from" and spawning a thread, which is a giant over-kill for a simple synchronous application which is happy with losing a packet that might be outdated anyway.

In plain C sockets this can be achieved by setting SO_RCVTIMEO on a socket and adding a check in the main reading loop.

Configure flags while creating sockets.

2018-06-28T11:33:03.683000Z

On Windows, when we create tcp sockets, asio library creates a Windows socket via WSASocket in asio/detail/impl/socket_ops.ipp.

WSASocket function has an option to provide some flags which changes some properties of the socket being created e.g., whether the socket is inheritable by the process' children. More details here

It would be helpful if asio library provides an option to configure this flag.

Ability to check that we're on a specific strand

2012-12-12T14:51:17Z

It would be great to be able to code assertions into our methods that the code is being called as expected. This can also serve as useful documentation fo developers. For example:

class Foo {
public:
Foo(asio::strand& strand)
: strand_(strand) {
}

void foo() {
assert(strand_.running());
...
}

private:
asio::strand& strand_;
};

strand::running() would return true if the strand is running in the current thread. The assertion states that foo must be called from strand_.

This information is already maintained by the strand implementation. strand::dispatch() needs to know if the currently thread is executing the strand already so that it can decide whether to execute the handler immediately (on the current thread) or post it to a queue of handlers.

support for MSG_DONTWAIT to save a few system calls

2012-09-04T08:19:58Z

We have a use case with a tcp connection pool, where we want to do a quick check if a connection is still valid before re-using it.

We currently basically do it as follows (using the boost version of asio):

boost::asio::ip::tcp::socket & s = get_socket();
s.non_blocking(true);
char buf[1];
s.receive(boost::asio::buffer(buf, sizeof(buf)), s.message_peek);
s.non_blocking(false);

This nicely reports a connection that was closed by the peer, in which case we can reconnect. However, it uses a number of additional system calls to set the socket to non-blocking and back to blocking that could be eliminated on Linux, and maybe also on other OSes.

Linux supports MSG_DONTWAIT. It would be nice if asio could also support this flag, if it is available. Then we could do:

boost::asio::ip::tcp::socket & s = get_socket();
char buf[1];
s.receive(boost::asio::buffer(buf, sizeof(buf)), s.message_dontwait | s.message_peek);

This would eliminate the system calls to set the socket to blocking / non-blocking.

We have tried:

boost::asio::ip::tcp::socket & s = get_socket();
char buf[1];
s.receive(boost::asio::buffer(buf, sizeof(buf)), MSG_DONTWAIT | s.message_peek);

This however blocks the program. For example, the above code goes down to socket_ops::sync_recv, which has:

// Operation failed.
if ((state & user_set_non_blocking)
|| (ec != boost::asio::error::would_block
&& ec != boost::asio::error::try_again))
return 0;

But for MSG_DONTWAIT to work, sync_recv would need:

// Operation failed.
if ((state & user_set_non_blocking)
|| (flags & MSG_DONTWAIT)
|| (ec != boost::asio::error::would_block
&& ec != boost::asio::error::try_again))
return 0;

With this patch, the receive call with MSG_DONTWAIT works as expected. In socket_ops.ipp, more functions similar to sync_recv could add support MSG_DONTWAIT in this way.

It would be nice to be able to use MSG_DONTWAIT with the asio API. If necessary we can go more low-level through s.native_handle().

iovec -> buffer

2011-03-01T02:10:43Z

The following patch allows one to use struct iovec directly as the value_type of a mutable/const buffer sequence.

This need arose from the desire to use an old buffer interface, that was compatible with the readv/writev system calls, and thus provided access to its internal storage via arrays of iovecs (and a length of course) With this patch, the buffer object is easily represented with a mutable/const buffer sequence class that provides &struct iovec[0] as begin() and &struct iovec[iov_count] as end()

Support of C++0x move semantic

2011-01-31T18:39:50Z

Any plans of using C++0x move semantic in Boost.Asio?
Usage of C++0x move semantic (already implemented in MSVC 10, GCC, ICC 12) can significantly reduce calls to handlers' copy constructors replacing most of them with calls to handlers' move constructors – especially at custom memory allocation support (I mean creation of local handler’s copy on the stack) – move constructors usually have resource-steal semantic which doesn’t throw (or throw rarely comparing to copy constructor).
Compare copy constructor and move constructor of boost::shared_ptr which is often used with Boost.Asio. It is the most often called function when using “shared_from_this()”-approach and its usage of CAS can significantly degrade performance in multi-threaded application (at modern multi-core/multi-processor systems).
It would be very interesting to compare performance (take “echo_server” project from https://sourceforge.net/projects/asio-samples/\) of different versions of Boost.Asio – without move semantic support and with it.

Delay SSL initialization

2009-07-21T08:49:00Z

When SSL header are included, ASIO tries to initialize SSL on application startup (class openssl_init). This approach makes impossible delayed loading of SSL dll's (/DELAYLOAD option with MSVC linker), which would allow to deliver an application without SSL dll's, if SSL-related features are not really used.

DCCP support

2009-04-14T06:11:58Z

DCCP is a connected datagram protocol (IPPROTO_DCCP) which provides connection management in situations where UDP will be too low-level, but full overhead of TCP is not required. It also makes firewall configuration for datagram based protocols considerably easier.