[ros-users] [Discourse.ros.org] [Next Generation ROS] IPC in ros2

Angelo Corsaro ros.discourse at gmail.com
Mon Oct 2 21:43:37 UTC 2017



Hello @gbiggs,

First of all I'd like to point out that I am one of the author of PrismTech's/ADLINK XRCE proposal, thus you may think I am giving you my perspective, in that case I urge you to read original documents to see how what I am providing here are facts. That said, let me make a few rectifications to some of the points above. 

You say:

_* They [PrismTech] believe that their proposal is more efficient in the wire protocol (trying to save every single byte possible), and supports brokered as well as peer-to-peer communication._

We are Engineer and Mathematicians not priests. Thus we don't believe we measure ;-) You can find the result of our analysts here http://bit.ly/2yjUZMy but you are welcome to derive them by reading both specs.

_* PrismTech believes that they have presented their final submission in Brussels (June) and so were expecting to vote for acceptance in New Orleans (September), but because there are still two competing submissions, and no final submission document was received (only a presentation), this is not possible._

This is also partially correct. We had asked to present what would have been our final proposal in Bruxelles to give a chance to the task-force to digest and one more opportunity to the competing team to join. This has nothing to do with the Vote-to-Vote and the fact that the task-force did not decide to allow the Vote-to-Vote procedure. The OMG has very complex rules... I know that can seam strange, and they still surprise me after having spent more than 10 years dealing with it.

_* Their submission is only about the protocol, it does not say anything about the API._

The RFP (which I wrote) asks for a protocol not for an API.


_* This proposal appears to be a very complex protocol with a lot of options in message header structures. An implementation would have a lot of choice points during the decoding of a stream of messages. The decorator idea especially may save bytes on the wire (and in message construction buffers) in some cases, but it complicates the protocol implementation._

First off, the protocol has a single byte header of which only 3 bits are used for flags and the remainder 5 bits for message-id. There are two flags that are used consistently to identify Reliable and Synchronous messages and another few flags used to mark the presence or absence of some information in the message. Personally I don't find that daunting complex,  it is quite normal in protocol to use flags to this end. 
Additionally, you may argue that this may add some complexity in the message parsing -- but again -- I think that checking a flag and deciding wether some field is going to be present or not does not belong to the realm of hard. It is also worth  pointing out that some flags are just informative and don't require any kind of branching in the decoding. Finally, what I can tell you is that with this protocol we have measured performances that  literally blow away RTPS! If you are curious we'll share the numbers... Or better make available the code for you to see with your eyes ;-) And BTW, if our complex specification can fit in 1KB and RTI&Co simple protocol fits in 43KB... There is something wrong... Thus either our is not so complex or their is not so simple :-)

As I've explained several times during previous OMG meeting we have customers count bytes, and in some use cases they are not willing to spend more than 7 bytes wire overhead for data samples. Our proposal currently has 4 compared to that of RTI/TwinOaks/eProsima which has 16 bytes. We have had our implementation run on a Makeblock robot using BLE with an MTU of 20 bytes.  You can check the comparison on this deck http://bit.ly/2yjUZMy and should wonder why the competing proposal did not provide a proper analysis of the wire overhead. Additionally when leveraging batching we have a wire overhead of (3+n)/n where n is the number of samples being batched.


Some other thing worth point out is that the protocol allows for data to be pushed, pulled or periodically pushed or pulled. The write protocol also allow to pace the streaming of data that results from a remote query. This is extremely important when dealing with resource constrained nodes that need to consume data little by little.

I did not hear RTI saying:

_* They also received 3 AB reviews, which they claim were supportive and did not find any non-editorial problems._

But this is far from being true. The AB review should be public and I can ask permission from the AB to post those. The truth is that the two reviews of the AB raised questions concerning whether the submission was actually answering the RFP. The reason why RTI did not want to vote is that their submission -- if selected would have been killed by the AB. That is as simple as that. 

I'd like to understand why you say this:

_My summary:_

_* The submissions are very different. PrismTech is aiming for cutting down the bytes used by the protocol to the absolute minimum at the expense of all else. RTI/eProsima/TwinOaks are favouring some overhead in order to achieve a simpler and more robust protocol and implementation._

What do you think is our submission cutting out? We are wire efficient yes, extremely wire efficient but at the same tine we support:

- Dynamic Discovery (RTI does not, please read their spec!)
- Peer to Peer Communication (RTI does not)
- Client to Broker Communication
- Non IP Transports (RTI does not)
- Generalised Queries (RTI only supports DDS-like queries)
- Push/Pull/Periodic-Pull and Periodic-Pull Readers
- Unicast and Multicast communication -- for both client to broker and peer-to-peer
- Durability

At this point my question is have  you've read both specification? If not, I suggest you do our is available here http://bit.ly/2wtJL3m 

I hope this was useful in clarifying a few aspects and I am looking forward to get some feedback once you'll have read both submissions. I'll also be more than happy to answer any question you may have about our protocol.

A+





---
[Visit Topic](https://discourse.ros.org/t/ipc-in-ros2/2619/11) or reply to this email to respond.




More information about the ros-users mailing list