Hackathon Proposal:websocket improvements
| Title | websocket improvements |
| Sponsor | Pat Callahan |
| Supporters | |
| Status | Proposed |
| Summary | The main goal is to fix a bug in skipped or delayed changes in property values sent over websockets. Fixing this bug will take little effort, but there is more to do if we want to tackle it during the hackathon or later. There may or may not be situations with a significant delay between websocket packets. We need to find out if that happens or not. |
| Background | flightgear/src/http websocket area |
| Details | |
| Skills | |
| Notes | A secondary goal is to prevent updates that report the same value over the websocket repeatedly. Fixing this will remove unnecessary traffic over the WebSocket, reducing latency for actual property changes.
A third goal in this area is to upgrade the Mongoose web server version in flightgear. This would have the advantage of supporting additional protocols such as MQTT. If you are familiar with the internals of how http/tcp/websockets work, that would be great, but if not, this would be an opportunity to pick up some details. I've been poking around and have a few TCP-related questions to find answers for. One thing I'm looking at ahead of time is how to determine in the websocket if a property is or is not a float or double. I want to keep the previously transmitted values of any float or double property values as floats or doubles instead of as strings. This would allow us to quickly determine if a change in the property value at high precision would appear as a change in value at the lower precision transmitted over the socket. Currently, values that differ by infinitesimal amounts are being transmitted repeatedly, with the same apparent value in the packet, needlessly crowding out changes that matter, increasing traffic on the WebSocket and increasing latency for everything. The current implementation responds to any change in a floating point number by updating the property via the websocket. As a result, identical property values appear in the websocket packets because the packet values have less precision. 10e-6 vs 10e-7 or 8. I can't imagine needing changes less than 10e-3 or e-4. One option is to make the precision configurable per property from the client side. If not that, then at least a configurable property value with the minimum transmittable change for floats and doubles. Maybe both. This might be a bigger change and might require some up front discussion with others. I'll be working on a local branch which I'll be pushing to https://sourceforge.net/u/callahanpa/flightgear/ and https://sourceforge.net/u/callahanpa/simgear. |