Excellent questions:
1. On some work loads we have seen higher than desired CPU hits. Specifically about 10% higher than rosmaster for certain rospy publishers. This is due in part to an upstream bug in rospy and a lack of adequate caching on the vapor side, [you can track here](
https://github.com/roshub/vapor_master/issues/4). Typically most pronounced on small systems like raspi. Typically not noticeable on modern x86 systems.
2. This is a great idea, a middleware/filter feature here similar to the approach in the server in rosbridge_suite would make a lot of sense for some use cases. We'd welcome a feature request so we can design it out together.
3. Security was sadly a non-goal of this rev. We also have some tools at a different layer coming in the near future so stay tuned. We expected a desire to become SROS compliant, not presently on the road map on my side but we should explore it more. Fundamentally the security threat model is very similar to stock ROS 1 presently, with the exception of the securing the db connection via SSL and mongo user+token. Major concern from my side is that all security features must have excellent UX... poor UX in security is nearly as bad as no security. So lets continue discussion in issues and make sure we can deliver great UX.
4. Vapor should happily run on kinetic, we just haven't tested there. Would love feedback if you've tried it.
---
[Visit Topic](
https://discourse.ros.org/t/vapor-master-a-distributed-high-availability-rosmaster/7375/3) or reply to this email to respond.
If you do not want to receive messages from ros-users please use the unsubscribe link below. If you use the one above, you will stop all of ros-users from receiving updates.
______________________________________________________________________________
ros-users mailing list
ros-users@lists.ros.org
http://lists.ros.org/mailman/listinfo/ros-users
Unsubscribe: <
http://lists.ros.org/mailman//options/ros-users>
(text/plain)
