What is the current behaviour of UDP receiver, when dealing with out-of-order packets? (5.11.x / 5.12.x release)

[chengguizi]

I just notice there is some new development on UDP design with eCAL, pretty interesting.
#1271

It reminds me a question releated to the design of the UDP pub/sub of eCAL. May I know if the current release version of eCAL handles out-of-order UDP packages, during the reception of the eCAL message (say ~1MB big)? In other words, if packages are received out of order, will the design tolerate that and still recover the right full eCAL message?

Now I see there is a de-fragmentation talked about in this PR. Does it mean it is improving the situration of the out-of-order UDP package reception?

Thanks!

[FlorianReimold]

Hi @chengguizi,

• The current PRs re-organize the current UDP code, but don't introduce new features. The goal is to reduce the coupling of eCAL to its own UDP implementation. We are currently working on a new implementation of the UDP code that will have a proper API and can also be used standalone. The new implementation will be easier to test and maintain.
• 1 MiB packages will always be critical, as an ethernet frame only fits 1500 bytes. UDP is a fast but unrealiable protocol, meaning that if one of those 1500 byte fragments is lost, your entire 1 MiB message is gone. I don't say that it cannot work, but I would recommend using the eCAL TCP layer for those large messages.
• Out of order fragments are handled both in the current and in the future UDP implementation. Out-of-order fragements will be buffered and reassembled once the entire message is complete
• Can you specify what we need to improve with out-of-order "packages"? Does your term "package" refer to a single fragment (i.e. a UDP datagram) or the reassembled eCAL message?

Kind regards
Florian

[rex-schilasky]

Hi @chengguizi, yes your deduction is fully correct. The current implementation will not resort out of order packages in any kind. So if a data package arrives before the initial message header package or if data packages arrive in the wrong order, the whole message is lost. My understanding of package is the higher level eCAL udp fragment, not the UDP datagram.

[chengguizi]

Hi @rex-schilasky May I clarify further what is the difference between the invidisual eCAL udp fragment and UDP datagram. From my limited inspection, the eCAL udp fragment is essentially one UDP packet / datagram. Or more precisely, the eCAL udp fragment is inside the data section of one udp packet / datagram. Am I correct?

Meaning to say, the following line is to receive the content of UDP package, and cast it later to a eCAL udp fragment

ecal/ecal/core/src/io/udp/ecal_udp_sample_receiver.cpp

Line 140 in 0f16b39

const size_t recv_len = m_udp_receiver.Receive(m_msg_buffer.data(), m_msg_buffer.size(), CMN_UDP_RECEIVE_THREAD_CYCLE_TIME_MS);

Am I still correct saying all these?

[chengguizi]

If so, could we implement some simple logic here to buffer the "advanced" eCAL udp fragment that arrive before the header, and then release them after the header arrives. This way we should have a much higher chance of recovering big UDP data, as long as there is no actual packet loss (which is quite possible if we work on LAN i think)

[FlorianReimold]

For fragmented messages, the current eCAL v5 UDP protocol requires an entire UDP datagram to be transmitted for telling the receiver about the fragmented package. This datagram (called "header" in the current implementation) cannot contain any actual user payload. The payload is transmitted with the next datagrams (called "payload" in the current implementation). And yes, it looks like an out-of-order header would cause the message to be lost. This can be considered to be a bug.

The new implementation that I am working on will:

• obviously handle out of order datagrams by simply storing them in a map. And yes, it does that for those "header" and the "payload" datagrams
• properly look at the sender endpoint when reassembling fragmented messages
• require less threads and - more importantly - no polling of sockets
• Probably introduce a new protocol that doesn't require a "header" to be sent alone for fragmented messages (because that's inefficient)

[chengguizi]

This would be a fantastic solution. Very looking forward to it!

[chengguizi]

@FlorianReimold Wondering if this "bug" fix is being worked on towards 5.13? Or would be available in the further future?

[FlorianReimold]

Good and bad news:

• Yes, it is being worked on
• No, I don't think it will make it in 5.13 :-(

The reason is that converting the special Windows NPCAP based UDP receiver to the new structure will take some additional time...

[chengguizi]

No worries! Will continue to look forward then :)