How network channel work about cyclonedds HOT 4 CLOSED

The "network channel" bit really means using separate transmit and receive paths for different priority bands. If you look at the code, it can have a tev (timed event) thread per "channel" for handling all background work, and a dq (delivery queue) thread for pushing data asynchronously into the reader history cache. The code actually matches proxy writers with these delivery queues based on the transport priority.

There are a few things that need to be done for this to be really useful. Firstly, there's a problem in that currently the only way to get data out is for the application thread to push it out, and that it always leaves the node via a single socket. There is no queueing, no asynchronous publisher mode, effectively no latency budget. This makes it kinda hard to do any interesting priority-based scheduling.

The sensible solution is to use an asynchronous publishing mode (still to be implemented), perhaps by default when the latency budget is greater than 0. That way, you can let the writer put the data in a priority queue for a "channel" and have another thread drain the queue. If you'd use a different socket per channel, so much the better, because you'd avoid the high-priority data being stuck (for however short a time) behind lower priority data in the socket's transmit buffer.

On the receiving end, you need multiple sockets for the same reason; and really also multiple receive threads that take data from these sockets. Now, obviously it can handle multiple receive threads already, and sockets are really low-level things that affect few parts of the code. So using different sockets and multiple receive threads is "just" a matter of a bit of administration.

As the discovery protocol allows you to override the default addresses for individual readers and the topic QoS has a transport priority field, you could choose the socket/port based on the channel that matches with the readers topic QoS and advertise that. Then way, if the writer follows the same topic priority setting, the data will end up in the right socket and be handled by the right thread; and if it doesn't follow it, the data will still arrive and still be delivered, but after taking the "wrong" route through the receive path.

The above is pretty trivial to do if you are ok with a less than optimal implementation — say, not use multiple sockets and just a single receive thread — and it gets progressively harder the nicer you make it (not much of a surprise there, I suppose) but I don't think it is really hard to do all this. I think there'd also be a nice opportunity to integrate what are "network partitions" into this; so that you can also map to threads/sockets on topic or partition names instead of priorities.

from cyclonedds.

Hi,
In RTI specification, it said it used the TOS of IPv4 to implement PRIORITY, and why not implement in this why for cycloneDDS?

from cyclonedds.

@jwcesign, excellent question :) Obviously, the answer is that IPv4 TOS should be used as well. I think all the other points I made are important because without those details you are not actually in full control over the entire data path, but yes ... stupid oversight of mine.

The more so because there is this

This element describes the DiffServ setting the channel will apply to the networking messages. This parameter determines the value of the diffserv field of the IP version 4 packets sent on this channel which allows QoS setting to be applied to the network traffic send on this channel.

That's part of the network channel stuff in the code, and so at the moment it just sits there doing nothing ...

from cyclonedds.

While we don't have network channels still, the question of how they work is answered, thus this can be relegated to the knowledge base 😄.

from cyclonedds.