Hello,

What about using:
- non blocking sockets
- sendmmsg Linux API with the native_handle of the socket
- async_wait functions provided by the ASIO sockets to wait when the socket is ready for more.

This way you'll be even more efficient because you'll use single system call instead of multiple ones and also you'll guarantee the ordering between the messages.

On Tue, Sep 17, 2024 at 4:59 PM Kalesis, Ioannis via Boost-users <boost-users@lists.boost.org> wrote:

Hello,

 

I am using boost.asio for udp sockets to broadcast multicast traffic.

 

For that, I am using async_send methods.

I am aware that there is no guarantee for the order of the completion handlers for the async_send calls, and for that reason I have implemented a queueing mechanism, where the coroutine waits for the current async_send to complete before moving forward to the next call.

However, given the low latency requirement of the application, I believe that the following approach may be more optimal:

  • The async_send operation would happen immediately one after another (not concurrently) without waiting for the previous ones to complete.
  • The queueing mechanism would be used but only for the post processing work completion handlers.

The above will provide both better latency (by sending the packets sooner instead of having to enqeue/spawn_co/dequeue) and still maintain the strict ordering requirement of the post processing work.

 

However, one concern that I have with this approach is with the “multiple” async_send calls being made one after the other.

After searching on this topic, I arrived at the conclusion that this is “safe” given that they are not composed operations so there is no risk that the data will be interleaved between packets.

The point that I need help understanding is whether there is a guarantee on the order of the packets being enqueued to kernels network stack.

For the following example:

```

udp_socket.async_send(packet1,…);

upd_socket.async_send(packet2,…);

 

```

 

Is there any possible way for “packet2” to be enqueued 1st in the kernel network stack?

Similarly, Is it possible for it to be sent by the OS 1st?

 

I acknowledge that even if everything went perfect on the machine, packets could still be received out-of-order to the clients and that is acceptable, however I would like at least to not have the application contribute to this as part of a software issue.

 

The application has multiple threads that run the same io_context with strands in place to have thread-safety.

My machine is a redhat 9, gcc 11.4

 

Thank you in advance for your time and cooperation.

Best regards

_______________________________________________
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users