Hi all, I have in previous (last winter IIRC) discussions on #flightgear claimed that modifying the MP protocol to only send MP properties that have changed would be problematic and break backwards compatibility.
I was wrong. It is in fact easy to implement and is nearly 100% backwards compatible (more on that below). The idea is simple: 1. Only include properties that have changed since the last packet was sent. 2. To cope with thee potential for message loss include the changed property in the next 4 packets too. 3. To ensure that newcomers have the full state include all MP enabled properties (i.e. a packet like those FG sends today) every 25 packets. The parameters 4 and 25 could of course be configurable. For the c172p (a fairly lightweight MP aircraft) the size (as reported by tcpdump) of most MP packets dropped from 470-480 bytes to 250-260 bytes, even in flight. That is a pretty significant bandwidth reduction. The patch: http://www.gidenstam.org/FlightGear/misc/more-efficient-mp-protocol.diff (In all 106 changed lines in src/Network/multiplay.?xx) Now, what about _nearly_ 100% backwards compatible? First, note that I've only made changes to the code that decides what properties to put in a MP packet. There are no changes to the code that process received MP packets, so there is very good chance that there are very few compatibility issues. I can think of two issues, the first one is real (I've seen it) the second I think is a non-issue but I'm not 100% sure. 1. At the receiver side a multiplay entry can be created without having all its MP enabled properties in place (since it first received packet might be a small one). This could cause animations to misbehave until the full state has been received (after at most 2.5 sec in the case of no packet loss). Worse, Nasal code activated (e.g. from the model file or from listeners) could try to read an so far uninitialized MP property and crash. This happened with my Submarine Scout but was easy to solve by a small change to the Nasal code. Alternatively, one could delay making the multiplayer entry visible in the property tree until the full state has been received (which begs the question how to detect that the full state has been received, though). 2. It is possible that sending property values at irregular intervals could upset the MP state interpolation done at the receiver's side. However, so far I have seen no indications of that being the case. Moreover, the rate of packet transmission and the interpolation parameters included in each packet are the same as before. Have I overlooked some other (potential) issue? Comments, suggestions and discussion are welcome! Making this change could make our mpservers able to cope with another two dozen users (or so). :) Cheers, Anders -- --------------------------------------------------------------------------- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel