TCPTransportInterface::send reports massive mismatched warning message when transfering user data by the unrelated channel_locator and remote_locator!

[chunyisong]

Is there an already existing issue for this?

• [X] I have searched the existing issues

Expected behavior

TCPTransportInterface::send method will never be called when transfering user data by the unrelated channel_locator and remote_locator.For example,on the writer side transfeing user data between reader locator and discover server locators.

Current behavior

I have a writer <locator:(physical port: 18010; logical port: 27410/27411) @ TCPv4:[172.16.220.8]:1796359770>,a corresponding reader <(physical port: 733; logical port: 37660/37661) @ TCPv4:[172.16.220.114]:2468086493> and their discovery server <(physical port: 17480; logical port: 17480) @ TCPv4:[172.16.0.202]:1145586760>. The writer matched the reader by the discover server and they transfer user data correctly.

But on the writer side,in the TCPTransportInterface::send method, massive mismatched warning message flood are reported accompanied with user data transfering between the unrelated discovery server locator and reader locator.Also,on the reader side the unrelated discover server and writer locators transfer data to each other as the writer side but intermittently.When sending high frequency (such as 10000/s) data,performance is decreased significantly even I delete waring message log code.

A few things I am confused about:

1. Should The discovery server transfer user data?If not so, the TCPTransportInterface::send method will never be called by the discovery server locator for user data transfering.
2. On the writer side,should reader or discovery server act as send channel to eache other? if not so,It will be no chance use reader channel locator send data to discovery server locator or vice versa ;
3. On ther reader side ,same problem between writer locator and discovery server locator.
4. On the writer side,if multi readers matched to the same writer,will readers locators try to transfer data to each other all the time wasting cpu time and log massive mismatched warning messages flood?

Here are some messages extracted from logs (Note:I Modified some log message code for detail,So Don't be surprised if the actual output is not same with the fastdds source code. ): On the writer side at 172.16.220.8: 2023-07-19 21:01:27.908 [RTCP Warning] OpenInputChannel (physical: 18010; logical: 27410) @ TCPv4:[172.16.220.8]:1796359770 2023-07-19 21:01:27.908 [RTCP Warning] OpenInputChannel (physical: 18010; logical: 27411) @ TCPv4:[172.16.220.8]:1796425306 2023-07-19 21:01:27.910 [RTCP Warning] OpenOutputChannel (physical: 17480; logical: 17480) @ TCPv4:[172.16.0.202]:1145586760 2023-07-19 21:01:37.914 [RTCP Warning] OpenOutputChannel (physical: 733; logical: 37660) @ TCPv4:[172.16.220.114]:2468086493

Massive mismatched warning Messages flood on the writer side:

On the reader side at 172.16.220.114 2023-07-19 21:01:20.334 [RTCP Warning] OpenInputChannel (physical: 733; logical: 37660) @ TCPv4:[172.16.220.114]:2468086493 2023-07-19 21:01:20.335 [RTCP Warning] OpenInputChannel (physical: 733; logical: 37661) @ TCPv4:[172.16.220.114]:2468152029 2023-07-19 21:01:20.335 [RTCP Warning] OpenOutputChannel (physical: 17480; logical: 17480) @ TCPv4:[172.16.0.202]:1145586760 2023-07-19 21:01:37.912 [RTCP Warning] OpenOutputChannel (physical: 18010; logical: 27410) @ TCPv4:[172.16.220.8]:1796359770

Intermittent mismatched warning Messages on the reader side:

Steps to reproduce

1. start a discovery server helping reader and writer matching.
2. start a writer on a machine publisheing a topic using best-effort and discover-server policy;
3. start a reader on other machine subscribing same topic using best-effort and discover-server policy;

Fast DDS version/commit

2.10.x 2.11.x

Platform/Architecture

Ubuntu Focal 20.04 amd64, Windows 10 Visual Studio 2019

Transport layer

TCPv4

Additional context

No response

XML configuration file

No response

Relevant log output

No response

Network traffic capture

No response