<div dir="ltr"><div><div>Hi,<br><br></div>zmq is pretty cool, and I've been using it in other situations with great success. In true UNIX tradition, it does one thing well, and integrates well with other stuff. It is also a fairly minimal library. I strongly endorse it.<br>
<br>cheers,<br></div><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, May 24, 2013 at 11:15 AM, Jonathan Bohren <span dir="ltr"><<a href="mailto:jonathan.bohren@gmail.com" target="_blank">jonathan.bohren@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span style="font-family:Arial,Helvetica,sans-serif;font-size:13px">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.</span><div>
<span style="font-family:Arial,Helvetica,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:Arial,Helvetica,sans-serif;font-size:13px">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].</span><div style="margin:0px;padding:0px;border:0px;vertical-align:baseline;font-family:Arial,Helvetica,sans-serif;font-size:13px">
<br></div><div style="margin:0px;padding:0px;border:0px;vertical-align:baseline;font-family:Arial,Helvetica,sans-serif;font-size:13px">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.</div>
<div style="margin:0px;padding:0px;border:0px;vertical-align:baseline;font-family:Arial,Helvetica,sans-serif;font-size:13px"><br></div><div style="margin:0px;padding:0px;border:0px;vertical-align:baseline;font-family:Arial,Helvetica,sans-serif;font-size:13px">
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.</div>
<div style="margin:0px;padding:0px;border:0px;vertical-align:baseline;font-family:Arial,Helvetica,sans-serif;font-size:13px"><br></div><div style="margin:0px;padding:0px;border:0px;vertical-align:baseline;font-family:Arial,Helvetica,sans-serif;font-size:13px">
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. </div>
<div style="margin:0px;padding:0px;border:0px;vertical-align:baseline;font-family:Arial,Helvetica,sans-serif;font-size:13px"><br></div><div style="margin:0px;padding:0px;border:0px;vertical-align:baseline;font-family:Arial,Helvetica,sans-serif;font-size:13px">
Most importantly, it wouldn't break any code.</div><div style="margin:0px;padding:0px;border:0px;vertical-align:baseline;font-family:Arial,Helvetica,sans-serif;font-size:13px"><br></div><div style="margin:0px;padding:0px;border:0px;vertical-align:baseline;font-family:Arial,Helvetica,sans-serif;font-size:13px">
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.</div>
<div style="margin:0px;padding:0px;border:0px;vertical-align:baseline;font-family:Arial,Helvetica,sans-serif;font-size:13px"><div style="margin:0px;padding:0px;border:0px;vertical-align:baseline"><br></div><div style="margin:0px;padding:0px;border:0px;vertical-align:baseline">
[1] <a href="http://www.ros.org/wiki/fuerte/Planning/IPC" style="margin:0px;padding:0px;border:0px;vertical-align:baseline;text-decoration:none;color:rgb(102,17,204)" target="_blank">http://www.ros.org/wiki/fuerte/Planning/IPC</a></div>
<div style="margin:0px;padding:0px;border:0px;vertical-align:baseline">
[2] <a href="https://code.ros.org/lurker/list/ros-sig-ipc.html" style="margin:0px;padding:0px;border:0px;vertical-align:baseline;text-decoration:none;color:rgb(102,17,204)" target="_blank">https://code.ros.org/lurker/list/ros-sig-ipc.html</a></div>
<div style="margin:0px;padding:0px;border:0px;vertical-align:baseline">[3] <a href="http://www.ros.org/wiki/fuerte/Planning/IPC/Minutes" style="margin:0px;padding:0px;border:0px;vertical-align:baseline;text-decoration:none;color:rgb(102,17,204)" target="_blank">http://www.ros.org/wiki/fuerte/Planning/IPC/Minutes</a></div>
</div><div style="margin:0px;padding:0px;border:0px;vertical-align:baseline;font-family:Arial,Helvetica,sans-serif;font-size:13px">[4] <a href="https://sites.google.com/site/arsalanakhter1/news/zeromqwithros" style="margin:0px;padding:0px;border:0px;vertical-align:baseline;text-decoration:none;color:rgb(102,17,204)" target="_blank">https://sites.google.com/site/arsalanakhter1/news/zeromqwithros</a></div>
<div style="margin:0px;padding:0px;border:0px;vertical-align:baseline;font-family:Arial,Helvetica,sans-serif;font-size:13px">[5] <a href="http://www.zeromq.org/intro:commercial-support" style="margin:0px;padding:0px;border:0px;vertical-align:baseline;text-decoration:none;color:rgb(102,17,204)" target="_blank">http://www.zeromq.org/intro:commercial-support</a></div>
<span class="HOEnZb"><font color="#888888">
<div class="gmail_extra"><br>-- <br>Jonathan Bohren<br>Laboratory for Computational Sensing and Robotics<br><a href="http://dscl.lcsr.jhu.edu/People/JonathanBohren" target="_blank">http://dscl.lcsr.jhu.edu/People/JonathanBohren</a><br>
<br>
</div></font></span></div></div>
<br>_______________________________________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@code.ros.org">ros-users@code.ros.org</a><br>
<a href="https://code.ros.org/mailman/listinfo/ros-users" target="_blank">https://code.ros.org/mailman/listinfo/ros-users</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Ingo Lütkebohle<br>Bielefeld University<br><a href="http://www.techfak.uni-bielefeld.de/~iluetkeb/" target="_blank">http://www.techfak.uni-bielefeld.de/~iluetkeb/</a><br>
<br>PGP Fingerprint 3187 4DEC 47E6 1B1E 6F4F 57D4 CD90 C164 34AD CE5B
</div>