IPC in ros2

Next Generation ROS
25

@gbiggs, thanks for taking the time of reading and analysing both submission. I wish more OMG attendees would follow your example :slight_smile:

There are a few observations I’d like to make beside to what Erik has just made.

  1. One of he main focus on wire-efficiency for use was to be able to support properly transport that have very small MTU or low byte-rate per hour. One example is BLE (Bluetooth Low Energy), which on most devices fixes the MTU to 20 bytes (and sometimes cannot be negotiated upward). The other example is LoRA in which 400 bytes can be sent at most per hour! Thus, it is not as if we are obsessed with efficiency, it is really a matter of relevance and applicability.

  2. I think that to understand our proposal you have to look at the mechanism we provide to implement the DDS mapping and DDS-like behaviour. In essence our properties mechanism allow us to map DDS QoS and for an XRCE implementation targeting the DDS interop, arguably QoS like deadline, transport priority, etc. etc. can all be implemented. It is in fact worth to remark how if you look at the DDSI-RTPS specification it does not specify how QoS are implemented – beside Realiability. Durability, Group Coherency and all the other are implemented at DCPS level. The same is true for XRCE. Do you start to see the analogy now?

  3. As you could see from http://zenoh.io our code is less then 2000 lines of code and can run OS-less. Thus if we compare protocol complexity, if as you mention RTI implementations is also around 2000 lines of code… Perhaps our protocol is not so much more complicated to implement :slight_smile: In fact, I’d argue that for those interested in implementing only the client-to-broker protocol the complexity is similar.

In any case, thanks again for your throughout analysis… And if you have any questions or curiosity on why certain things are how they are in XRCE, please don’t hesitate to ask.

@kydos

P.S. Did you realise why declaration can be are atomic? I guess with DDS you have experienced the challenge of needing a series of entities to be declared and having partial failures… Well that was one of the things we wanted to prevent.

P.P.S Notice that Resource ID can be arbitrarily small or big, and that there is a one resource ID identifies a resource constraint, meaning that multiple ID can be associated with the same resource… That has nice implications too…