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@mavt.ethz.ch <mailto:cedric.pradalier@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@mavt.ethz.ch
>> <mailto:cedric.pradalier@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@code.ros.org <mailto:ros-users@code.ros.org>
>> https://code.ros.org/mailman/listinfo/ros-users
>>
>>
>>
>> _______________________________________________
>> ros-users mailing list
>> ros-users@code.ros.org <mailto:ros-users@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@code.ros.org <mailto:ros-users@code.ros.org>
> https://code.ros.org/mailman/listinfo/ros-users
>
>
>
> _______________________________________________
> ros-users mailing list
> ros-users@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
--
Dr. Cedric Pradalier
http://www.asl.ethz.ch/people/cedricp