[ros-users] Generic message transport infrastructure

[Cedric Pradalier]

No plan to fix the problems. The really efficient way to pass the 
objects is to use nodelets, but I'm not sure it is always possible (e.g. 
do we want to have rviz as a nodelet in an application).

A memcpy based approach is not really possible due to the dynamic nature 
of the messages, so I don't see any way to avoid the serialisation step.


On 12/02/10 19:52, Josh Faust wrote:
> It doesn't look like any of the problems with the shmem transport have 
> been fixed 
> (http://code.ros.org/lurker/message/20100510.225110.8f5aa630.en.html), 
> do you have a plan to do so?
>
> Josh
>
> On Thu, Dec 2, 2010 at 10:05 AM, Cedric Pradalier 
> <cedric.pradalier at mavt.ethz.ch <mailto:cedric.pradalier at mavt.ethz.ch>> 
> wrote:
>
>     After a long time since my first post about a generic message
>     transport
>     architecture, we finally released it in the ETHZ-ASL message transport
>     stack.
>     Details about the ethzasl_message_transport stack can be found at
>     http://www.ros.org/wiki/ethzasl_message_transport
>
>     In addition to the framework, we also implemented a shared-memory
>     transport plugin and a udp multicasting transport plugin, and
>     instantiated the transport plugins for images and point-clouds.
>
>     The shared memory transport will not offer the same performance as
>     using
>     nodelets, but it can be an option when very large object needs to be
>     passed around while keeping different processes (there have been
>     several
>     discussions on this topic on this list).
>
>     The UDP multicasting transport is interesting when small objects needs
>     to be passed very quickly to many receivers on several machines (in
>     comparison, normal tcp transmission will incur a delay increasing with
>     the number of subscribers). Note that the plugin does not manage
>     object
>     fragmentation, and does not intend to do it (it would defeat the
>     purpose). This means that it will refuse to send object bigger
>     than 8092
>     bytes.
>
>     Other type-specific transport plugins can quickly be implemented using
>     this framework. As examples, I've adapted the theora and compressed
>     image transport, and implemented a decimated point cloud transport.
>
>     Ideally, the udp multicasting stuff (and shm) should go into the
>     core of
>     ROS, but I have not understood enough of the xmlrpc negociation to
>     implement it myself.
>
>     HTH
>
>     --
>     Dr. Cedric Pradalier
>     http://www.asl.ethz.ch/people/cedricp
>
>     _______________________________________________
>     ros-users mailing list
>     ros-users at code.ros.org <mailto:ros-users at code.ros.org>
>     https://code.ros.org/mailman/listinfo/ros-users
>
>
>
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>    

-- 
Dr. Cedric Pradalier
http://www.asl.ethz.ch/people/cedricp

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20101202/a1569291/attachment-0003.html>