Boost logo

Boost Users :

From: Klebsch, Mario (Mario.Klebsch_at_[hidden])
Date: 2024-09-18 13:53:15


Hi,

> I am using boost.asio for udp sockets to broadcast multicast traffic.
> ...
> 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?

The answer to this question does not really matter, since UDP does not give any guarantees on the order, the packets are received by the peer system. Packets may not only be re-ordered, they may arrive multiple times or may be lost.

73, Mario

Klebsch Mario
Funktion | R&D

Tel: +49 (0) 531 38 701 718
Raum: Braunschweig, E20

Diese E-Mail und die an sie angehängten Dateien sind ausschließlich für Personen oder Institutionen bestimmt, deren Namen oben aufgeführt sind. Sie können Informationen enthalten, die durch das Berufsgeheimnis geschützt sind und deren Weitergabe strengstens untersagt ist. Jede elektronische Nachricht kann geändert werden. ACTIA lehnt jede Verantwortung für diese Nachricht ab. Der Inhalt dieser Nachricht stellt keine Verpflichtung seitens unseres Unternehmens dar. Wenn Sie kein Empfänger sind, weisen wir Sie darauf hin, dass das Lesen, Vervielfältigen oder Verteilen strengstens untersagt ist. Wir bitten Sie daher, uns umgehend über diesen Brief zu informieren und diese Nachricht sowie eventuell beigefügte Unterlagen aus Ihrem Postfach zu löschen. Danke.

This e-mail and the files attached to it are intended exclusively for persons or institutions whose names are listed above. They may contain information that is protected by professional secrecy and the disclosure of which is strictly prohibited. Any electronic message can be modified. ACTIA declines all responsibility for this message. The content of this message does not represent a commitment on the part of our company. If you are not a recipient, we would like to point out that reading, copying or distribution is strictly prohibited. We therefore ask you to inform us immediately about this letter and to delete this message and any accompanying documents from your mailbox. Thank you.

Von: Boost-users <boost-users-bounces_at_[hidden]> Im Auftrag von Kalesis, Ioannis via Boost-users
Gesendet: Dienstag, 17. September 2024 11:37
An: boost-users_at_[hidden]
Cc: Kalesis, Ioannis <I.Kalesis_at_[hidden]>
Betreff: [Boost-users] Boost.Asio UDP sockets guarantee for ordering

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 list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net