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.
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.
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.