We are running into a problem when our application attempts to open a socket on a specific port for receiving UDP blocks when that port was already given to and is in use by RTI. We only use the UDPv4 transport option, so when RTI/DDS Software launches it will request 3 ephemeral ports from the OS (VxWorks/RHEL) for DDS communications for the send sockets. The default configuration that VxWorks uses for these ports is a pool between 49152 and 65535. There is a small chance that these port numbers will collide with ones that should be reserved for our application, which are in the ranges 55000-56000. When RTI is randomly given a port that our applicaiton needs, they fail to open that comm port.
Here is an example of what ports RTI is using, where 55336 was given to it by the OS but is a port that our application needs to use:
-> sockShow
fd domain proto rcv snd saddr:sport daddr:dport
326 INET UDP 0 3840 0.0.0.0:55336 0.0.0.0:0
328 INET UDP 0 0 0.0.0.0:65385 0.0.0.0:0
329 INET UDP 0 0 0.0.0.0:64576 0.0.0.0:0
330 INET UDP 0 0 0.0.0.0:7400 0.0.0.0:0
331 INET UDP 0 0 0.0.0.0:7410 0.0.0.0:0
332 INET UDP 0 0 0.0.0.0:7411 0.0.0.0:0
Our current path to resolve this issue is to update the VxWorks and RHEL OS setting to only return ports in the 49152-54999 range, which would guarantee that one of our reserved ports will not used by RTI. But before we change the OS, we would like to reach out to your to make sure there isn’t something else we could try first.
Is there a way to correct this issue by updating our QOS settings? Is there a way to make RTI open the sockets with the SO_REUSEADDR or SO_REUSEPORT options? If one of those options is used, it would allow multiple binds to same local port and could be one way to solve our issue. In our QOS setting, we modify some of the dds.transport.UDPv4.builtin.* options, but I don’t see any documentation that would allow us to specify using the SO_REUSEADDR or SO_REUSEPORT options.
Thanks for the help!
If your other appliction will use ports in the range of 49152 and 65535, can you instead change your DDS application's domain ID/participantID so that it will not use ports in that range?
It looks like if you used DDS domains between 0-166 then your dds applications should not use ports above 49149. You can easily calculate which port numbers DDS uses by default by using our udp port spreadsheet found here: https://community.rti.com/filedepot?fid=14
There are ways to change how domain IDs and participant IDs increment the dds ports chosen, but changing those settings would likely break compatibility with other "normal" dds applications without this change so I wouldn't reocmmend that.
Hoever if the conflict is from the source port used on outgoing packets, DDS choses a random port for that purpose which may be the conflict you're seeing
Hi John,
Unfortunately, I don't think RTI Connext DDS allows you to configure the DDS network layer to use SO_REUSEADDR or SO_REUSEPORT socket options for the ports that it uses to send data.
If you are on a project with an active support contract, I would suggest that for question like this, you may get a faster, and more official, response to your technical questions. Someone on your team should have been assigned support access, so you can work through that person or persons to get technical support from RTI.