[ros-users] Generic message transport infrastructure

[Josh Faust]

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> 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> 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
>> https://code.ros.org/mailman/listinfo/ros-users
>>
>
>
> _______________________________________________
> ros-users mailing listros-users at code.ros.orghttps://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
> https://code.ros.org/mailman/listinfo/ros-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20101202/44df69ed/attachment-0004.html>