[ros-users] ROS 2.0 transports and ROS 1.x transports

[Jonathan Bohren]

While this is about transports, I'm cross-posing this to ros-users since
it's pretty high-level and contains some background that I think others may
be interested in.

So back before Fuerte, there were also a bunch of people looking at
transport options, and there was an "IPC" SIG [1] with a mailing list that
died pretty quickly [2] but not before they put together a bunch of
thoughts at a meeting [3].

I was curious about how the ROS transport sausage was made and it's sort of
gross. TCP and UDP are all mangled together in roscpp and the underlying
code isn't really modular at all. That being said, I think the ROS
in-process communication with shared pointers is something special that we
should keep around, even if we gut everything else. That sort of constraint
to a finite set of shared pointer types (right now boost shared pointers
and maybe in the future c++11 shared pointers) is more constrained than
other middlewares are willing to go but I think we should really optimize
the ROS transport layer for the things that we do and keep this
functionality around.

Then I was looking at some of the alternatives for the inter-process and
inter-machine communication that exist today and provide a simple interface
to TCP/UDP/Multicast for a variety of languages, and zeromq (zmq) comes up.
The funny thing about zeromq is that almost a year ago, some people
at Bonn-Rhine-Sieg University of Applied Sciences analyzed ROS TCP
transport with zmq, and you can see their analysis here [4]. What I can't
find, however, is if they actually modified roscpp to try this. It seems
like we should contact someone from that group.

In the spirit of the new dependency-choice philosophy of ROS 2.0 I think
zmq is a really good choice because (a) it does what we would want ROS to
do, and (b) it's supported by a commercial entity [5]. If someone had time
to prototype a modification to roscpp in ros_comm as well as the master to
allow for zmq-based TCP/UDP/PGM (multicast) without changing the current
ROS API, that would be really cool. Fundamentally, it would work the same
as the current ROS networking architecture, which means we'd also be able
to compare performance to the current implementation.

Most importantly, it wouldn't break any code.

I know there are a lot of other far-out ideas (masterless stuff etc), but I
think _just_ replacing the ROS transport layer with something like zmq
would get us a LOT of capabilities and performance without having to
completely change how ROS works. Maybe there should be separate near-term
(1.x) and a far-term (2.0) efforts if there are enough people interested in
this.

[1] http://www.ros.org/wiki/fuerte/Planning/IPC
[2] https://code.ros.org/lurker/list/ros-sig-ipc.html
[3] http://www.ros.org/wiki/fuerte/Planning/IPC/Minutes
[4] https://sites.google.com/site/arsalanakhter1/news/zeromqwithros
[5] http://www.zeromq.org/intro:commercial-support

-- 
Jonathan Bohren
Laboratory for Computational Sensing and Robotics
http://dscl.lcsr.jhu.edu/People/JonathanBohren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osuosl.org/pipermail/ros-users/attachments/20130524/8c62e0fa/attachment-0003.html>