[ros-users] Generic message transport infrastructure

[Cedric Pradalier]

Good points.

Regarding data corruption, I'd would tend to consider it as an accepted 
risk for this type of transport, but I agree the plugin should be more 
resilient to this possibility.

On the other hand, I'm not quite sure how strong is the use case for the 
sharedmem transport, so I will wait to have at least one user before 
investing more time in improving robustness.


On 12/02/10 21:58, Josh Faust wrote:
> I was referring more to the fact that it's quite easy to make it crash 
> and/or have data corruption.
>
> On Thu, Dec 2, 2010 at 11:45 AM, Cedric Pradalier 
> <cedric.pradalier at mavt.ethz.ch <mailto:cedric.pradalier at mavt.ethz.ch>> 
> wrote:
>
>     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  <mailto:ros-users at code.ros.org>
>>     https://code.ros.org/mailman/listinfo/ros-users
>>        
>
>     -- 
>     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/d75c29cb/attachment-0003.html>