WAN client tcp configuration without listening address

[Desdroid]

Hi,

thanks for providing a DDS Router for DDS communication over WAN.
Unfortunately the provided client configuration of the WAN configuration documentation does not work. https://eprosima-dds-router.readthedocs.io/en/latest/rst/user_manual/wan_configuration.html
According to the docs and this example a listening address for the client is only required if the server uses udp only. I configured my server and client to use tcp. However when starting the Client DDS router without a listening address the following error will occur:
[RTPS_PARTICIPANT Error] Participant RTPSParticipant with GUID 01.0f.02.00.00.00.00.00.00.00.ca.fe|0.0.1.c1 tries to use discovery server over TCP without providing a proper listening port -> Function RTPSParticipantImpl

Providing a listening address lets the client DDS router start fine. However the communication does not work as I have not forwarded any ports to the client and also don't intend to do that.

I've installed ddsrouter, fastrtps, fastcdr and foonathan_memory_vendor from source as described in the docs, therefore I'm currently using the master version of ddsrouter.

My configuration:
Client:

allowlist:
  - name: HelloWorldTopic
    type: HelloWorld
  - name: rt/chatter
    type: "std_msgs::msg::dds_::String_"

WANClientParticipant:
  type: wan
  id: 2
  connection-addresses:
    - id: 1
      addresses:
        - ip: "<public_ip_of_server>"
          port: 11666
          transport: tcp

SimpleParticipant:
  type: local
  domain: 0

Server:

allowlist:
  - name: "HelloWorldTopic"
    type: "HelloWorld"
  - name: "rt/chatter"
    type: "std_msgs::msg::dds_::String_"

WANServerParticipant:
  type: "wan"
  id: 1# Id to generate the GuidPrefix of the Discovery Server of A
  listening-addresses:
    - ip: "<public_ip_of_server>"# Public IP of host Ha
      port: 11666# Port forwarded router Ra
      transport: "tcp"# Transport protocol


SimpleParticipant:
  type: local
  domain: 0

[rsanchez15]

Hi @Desdroid

First of all, eProsima/Fast-DDS#2394, which is a PR in Fast DDS repository, already solves the error you mention. In any case, that is just an error log that should be an info log so you should be able to communicate without any problems without having to set the listening address on the TCP client side.

Another error I see is in the server .yml configuration file. Could you remove all the comments from this file as I get an error that it is malformed.

If the error persists could you describe the network infrastructure you have, if you use any kind of containerization technology, if the server access ports are open, etc.

[Desdroid]

Hi @rsanchez15,

Thanks for your quick reply and the information on the Fast-DDS issue. I understand that the error should not be related to my problem and is safe to ignore. The .yml formatting is likely just due to copy and paste, I have no .yml errors.

My setup is simple: A Azure VM with ROS installed natively and DDS Router acting as the Server. A client on my local machine in wsl2 with ROS and DDS-Router installed natively. The port forwarding is set up server side and is working (I confirmed it with nmap).
I'm just trying to get the basic ROS talker - listener demo running with talker on the client and listener on the server. I updated both server and client to latest main of this repo.
My config (now uses a different ROS domain for the listener):

Client:

allowlist:
  - name: HelloWorldTopic
    type: HelloWorld
  - name: rt/chatter
    type: "std_msgs::msg::dds_::String_"

WANClientParticipant:
  type: wan
  id: 2
  connection-addresses:
    - id: 1
      addresses:
        - ip: "13.81.171.86"
          port: 11666
          transport: tcp

SimpleParticipant:
  type: local
  domain: 0

Server:

allowlist:
  - name: "HelloWorldTopic"
    type: "HelloWorld"
  - name: "rt/chatter"
    type: "std_msgs::msg::dds_::String_"

WANServerParticipant:
  type: "wan"
  id: 1                               
  listening-addresses:
    - ip: "13.81.171.86"              
      port: 11666                     
      transport: "tcp"              


SimpleParticipant:
  type: local
  domain: 1

I experimented a bit more and see some strange non-deterministic behavior:

With the config above I succeeded to get the talker - listener example running. However when i kill both - talker and DDS-Router - on the client and restart them the communication occasionally won't work anymore. In this situation the DDS-Router server flooded its log with the following warning:

2022-01-19 10:37:02.918 [RTCP Warning] SEND [RTPS] Failed: Not connect: 23912 @ IP: <eth0-ip-of-wsl> -> Function send

Do you have any idea where this behavior may originate from?

[rsanchez15]

Hi @Desdroid

We have already identified the bug you mentioned and we are working on it by implementing the bugfixes in the Fast DDS repository. As soon as we have the solution I will inform you of the branch of this repository where the bugfix is located so you can test it since the process of review and merge in the main branch is rather slow due to all the tests that are performed.

Moreover, although we can reproduce the warning you mention, the communication is reestablished between both DDS Routers. So I need you to answer me two more questions:

1. Does the re-connection issue you report occur whenever you drop the DDS Router and talker running on your LAN or only on sporadic occasions?
2. How do you stop these processes? From your comment it seems that you kill the processes. Could you tell us if you kill the processes as you say or instead you terminate them with a Ctrl+C signal, so that both are closed in an orderly fashion?

[Desdroid]

Hi @rsanchez15,

Does the re-connection issue you report occur whenever you drop the DDS Router and talker running on your LAN or only on sporadic occasions?

It does only happen sporadically. If it happens it often takes multiple restarts to work again though.

How do you stop these processes? From your comment it seems that you kill the processes. Could you tell us if you kill the processes as you say or instead you terminate them with a Ctrl+C signal, so that both are closed in an orderly fashion?
Indeed this seems to have been the problem.

I stop the processes with the kill command, which by default sends SIGTERM. Using Ctrl-C or SIGINT lets the process terminate gracefully with the log Finishing DDS router execution correctly which did not appear with SIGTERM.
I could not replicate the bug i mentioned with Ctrl-C / SIGINT.
Therefore you can close this issue, thanks a lot for your help. May I know why you don't shutdown gracefully on SIGTERM ?

[rsanchez15]

Hi @Desdroid,

As you said, I'm closing this issue as your issue is solved.

Also, we take into account your suggestion to shutdown gracefully on SIGTERM and we'll try to implement it in the following days.