eboasson
commented
12 months ago Finally, my question: would it not make more sense to send the "wake up" termination packet for the thread via localhost, instead of the interface that cyclone is bound to?
That is a good question indeed. There are probably two things worth considering:
- For the receiving code there is no difference whether it is a multicast packet or a unicast one. However, if there are multiple DDS processes listening on that port, then only a multicast is guaranteed to reach them all. A unicast instead gets delivered to one and that one might not be the one that needs it. I think Linux has a feature where it delivers a unicast to a different socket each time, but using that would be tricky, too (something like resending the packet while detecting cycles, but that's all quite scary).
- Sending it via loopback should work fine as far as firewalls and disconnected wires are concerned, but multicast over loopback on Linux is a tricky subject — it seems to work fine for IPv4 despite the kernel claiming it doesn't, but it doesn't seem to work for IPv6. I have something in the works that incidentally hacks around that weird detail, unfortunately I have to do it in spare time because of the things I get paid to do.
Something that works reliably with IPv4 would already be a great improvement. I think your idea might should work. Given the above, I think the easiest way would be to create a new socket with the outgoing multicast interface set to 127.0.0.1, and only do this if it using UDPv4. (Come to think of it, technically, there's no guarantee of a loopback interface nor that it uses 127.0.0.1 ... nor that 127.x.y.z is a loopback address. Oh well, we can always add an option to disable it for people that like to have a crazy setup.)
Finally, if you'd like any clarification on what I meant just ask!
cfveeden
I've been looking into this issue this and I have a question. Before I get to my question, I need to explain the test setup first.
To avoid having to install anything extra or requiring a specific network setup, I set up the following test.
I create a dummy interface with the following:
Then I do a
export CYCLONEDDS_URI=file://...to point to cyclone to my xml setup that uses that interface:I start a publisher and send SIGINT to the terminal, and it hangs:
Granted, the network setup is probably wrong due to the dummy interface I created, but that doesn't really matter for the question I'm working towards. I've also tested it on real interfaces and similar things happen. I've seen this comment ascribing this sort of behaviour to the use of multiple threads for receive queues, so I check the open ports using
lsofand grepping for udp. With some edits, it looks like this:The hanging thread terminates when I write something arbitrary to port 7401 on localhost:
If I repeat the test, but take the interface down while it is running with
ip link set dummy0 down, I see the following:Which is also recoverable with the same netcat command.
Finally, my question: would it not make more sense to send the "wake up" termination packet for the thread via localhost, instead of the interface that cyclone is bound to?