[14652] Incorrect UDP receiver buffers size when configuring UDPv4TransportDescriptor::maxMessageSize

[ma30002000]

Is there an already existing issue for this?

• I have searched the existing issues

Expected behavior

Receive complete DDS messages sent over UDP.

Current behavior

Received DDS messages get truncated if they are larger than maxMessageSize.

Steps to reproduce

Configure maxMessageSize < 64 kb. Try to receive messages from an endpoint that has a larger maxMessageSize configured.

Fast DDS version/commit

all

Platform/Architecture

Other. Please specify in Additional context section.

Transport layer

UDPv4

Additional context

Per default, UDP transport of FastDDS sends UDP packets up to 64kb of data, which get
fragmented at the IP layer when they do no fit the MTU of a network interface.
When changing the maximum message size to a lower value (in my case because of having
issues with broken network devices dropping certain types of fragmented IP packets),
data fom endpoints transmitting larger messages can apparently no longer be received.

The issue seems to be located in UDPTransportInterface.h:

[...]
uint32_t max_recv_buffer_size() const override
{
    return configuration()->maxMessageSize;
}
[...]

This code will lead to the UDP receive buffer being as large as the larges message size
that is supposed to be sent, which is obviously too small to contain a larger message
sent by a differently configured endpoint. The message will thus get truncated and dropped
due to inconsisten length fields.

My proposal ist to change the code mentioned above to

uint32_t max_recv_buffer_size() const override
{
    return configuration()->receiveBufferSize;
}

Not only does it fix the mentioned issue but also makes more sense vocabulary-wise...

XML configuration file

No response

Relevant log output

No response

Network traffic capture

No response

[MiguelCompany]

@ma30002000 Currently, as stated in the documentation, maxMessageSize is the Maximum size of a single message in the transport. Although it is not explicitly mentioned, it applies to both directions.

Member receiveBufferSize on UDPTransportDescriptor is meant for the receiving buffer size of the OS socket, and could have space for several incoming datagrams.

We could have different members on the transport descriptor for incoming and outgoing messages in the future. That's why I marked this as an enhancement.

In the mean time, you could use the Chaining of transports feature as a workaround.

[ma30002000]

Ok, I understand the usage of receiverBufferSize now more clearly. I was not aware the default value is read from the OS in UDPTransportInterface.cpp:

[...]
    if (configuration()->receiveBufferSize == 0)
        {
            socket_base::receive_buffer_size option;
            socket.get_option(option);
            set_receive_buffer_size(static_cast<uint32_t>(option.value()));
[...]

What distracted me was that while on my Linux system this is an more or less expected value of 106496 bytes, it is 65536 bytes on my windows 10.0.19042, which looked quite similar to the default s_maximumMessageSize of 65500 bytes. Isn't this a little low? This would mean that the OS buffer would include only a single maximum size UDP packet before it is passed on to the application...

I think I would agree on configuring the limits for incoming and outgoing RTPS message separately.

[JLBuenoLopez]

I have moved this issue to the proper discussion forum. According to our CONTRIBUTING guidelines enhancements are to be tracked and discussed in the Ideas forum, leaving the Issues as proper bug reports.

Thanks @ma30002000 for your contribution!