Hi Brian,
first of all thanks for the detailed reply. I think most of the people
interest in this topics are familiar with the design documents and, by
the way, thanks for developing things such in the open. :)
I've just a couple of points that for me, having experience with
different message-oriented middleware architectures (AMPQ, ActiveMQ,
0MQ, etc), and ESBs, are not clear in such evaluations.
On 28/09/15 22:08, Brian Gerkey via ros-users wrote:
> While you might consider zmq a "known thing," and indeed it is widely
> used in a number of distributed systems, it's insufficient to say, "use
> zmq." zmq specifies only the transport part of the system (how sockets
> are handled), saying nothing about discovery (how participants find each
> other) or serialization (how data is encoded on the wire).
The nice thing about ZMQ is the C4.1 community process, where group of
interests (like the robotics community) can propose and endorse any
change or standard to be build on top of the existing technology. This
can help in creating even more consensus around the ROS middleware.
Using the same community process discovery protocols are being build on
top of the existing infrastructure. For instance ZRE (ZeroMQ Realtime
Exchange Protocol) [1] along with its reference implementations [2], [3]
in C/C++ and Python can be used for exactly that purpose.
Serialization is generally left to the user in many of the existing
message-oriented middlewares. If one wants to rely on existing open
standards the new IETF CBOR [4] specification can be a good starting point.
> zmq doesn't support unreliable transport, so you'd also need to add your own solution there
> (e.g., managing UDP sockets manually).
Yes it does. It can be used it over UDP with Pragmatic General Multicast
(PGM), both in its raw and encapsulated versions. The use of PGM is
standardized by IETF in RFC3208 [5].
> At OSRF, we looked carefully at this issue, considered a wide variety of
> options, and came to the conclusion that while we could build on things
> like zmq, we would really be defining and building another custom
> middleware. And things would just get more custom as we want to add
> features like quality-of-service (QoS). Do you want to support
> store-and-forward of messages? Priority among messages?
> Limited-duration delivery retry? Well, you have to invent your own
> rules for handling those cases, in addition to writing (and testing and
> debugging) the code to implement them.
Nice thing to note is that ZeroMQ makes exactly one guarantee: all
messages are complete - you will never receive partial messages. It
makes no guarantee of reliability. This guarantee is the true difference
respect other enterprise message queues and it has been motivated by
specific reasons [6]. One of which is that developing store and forward
message systems is heavily dependant on the application use case and
"one-size-fits-all" is more the holy-grail of software engineering than
a reality.
So while all the above concern are true I'm still wondering why such
guarantees should be enforced as default, while not all of the robotics
use cases require so (think of sensors data streams rather than high
level concepts), and not left as an optional transport where the user
needs to fully understand the limitations of the use case and hopefully
control those. Think about assessing how much information can be
buffered before breaking the system and hopefully control such
behaviour. In this case neither "fire-and-forget" and "retry-forever"
are viable options cause they sit at the extreme edges of the spectrum.
> By contrast, DDS (and its underlying wire protocol, RTPS) is an open,
> end-to-end middleware specification that is relied upon for serious
> applications in labs and industries around the world. And the
> specification includes extensive QoS settings that give you essentially
> any kind of behavior between UDP fire-and-forget and TCP retry-forever.
> That's exactly what we need for robotics applications. And there are
> multiple well-tested implementations of the specification.
Open specification true but concerns over IP and patents can make the
same users turn in the other direction especially if looking for
commercial applications built on top of ROS.
That said it is a pleasure to see the ROS 2.0 topic being discussed in
the open. :)
Cheers,
Valerio
[1]:
http://rfc.zeromq.org/spec:36
[2]:
https://github.com/zeromq/zyre
[3]:
https://github.com/zeromq/pyre
[4]:
http://cbor.io/
[5]:
http://tools.ietf.org/rfcmarkup?doc=3208
[6]:
http://zeromq.org/area:whitepapers
-----
We invite research leaders and ambitious early career researchers to
join us in leading and driving research in key inter-disciplinary themes.
Please see
www.hw.ac.uk/researchleaders for further information and how
to apply.
Heriot-Watt University is a Scottish charity
registered under charity number SC000278.
_______________________________________________
ros-users mailing list
ros-users@lists.ros.org
http://lists.ros.org/mailman/listinfo/ros-users
(text/plain)