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 > > > 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 >> > > 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 >> 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 > > > _______________________________________________ > ros-users mailing list > 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