Support for lossy connections

[FieldSwan]

Currently we use websockets to do all communication with the rosbridge_server. This works great for reliable connections to a robot, but under spotty WiFi conditions or with mobile hotspots, the performance can be undesireable. Specifically, users will often see "catch-up" behaviors where the queue of sent messages will be received all at once as soon as bandwidth increases unless the websocket is disconnected first. From my understanding, this is inherent to the websocket protocol. The websocket_ping_timeout does help as we can use this to disconnect and reconnect the websocket to effectively kill old messages, but it doesn't feel like a clean solution to the problem and may introduce new issues if the timeout is too short.

What is the feasibility of using UDP to send messages with rosbridge in situations where users only care about the latest messages (OK to drop old ones that fail to send/receive) and transport reliability guarantees are not needed?

[Roald-Schaum]

#1150 will add support for ROS' QOS settings, which allows you to drop old/'stale' messages based on various environmental states (as seen here).

[FieldSwan]

#1150 will add support for ROS' QOS settings, which allows you to drop old/'stale' messages based on various environmental states (as seen here).

@Roald-Schaum QoS profiles can help, but this goes beyond that, especially if the rosbridge_server is local to the robot (and thus unlikely to be greatly affected by ROS QoS).

When rosbridge_server receives messages from ROS2 it will then add the messages to the websocket queue (system level socket queue) to communicate with web clients. The problem with this is that messages added to the system socket queue are not removed/expirable without disconnecting the websocket and making a new socket connection. Web clients with lossy connections will see "catch-up" behavior (FIFO) whenever they temporarily lose connection (up to the websocket_ping_timeout amount) when "jump" behavior would be more desireable.