Anders Gidenstam wrote > 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). :) >
IRC original design of MP included the concept of transmitting some properties "on change" as you describe. It was dropped early on in the development because of the difficulties of aligning the model states for people joining at intervals, and worries about dropped packets. It was suggested that when someone joined that could force all participants to transmit their full state, but this was discarded on the grounds that this, far from saving bandwidth, would in practice increase it. On the other hand, back then bandwidth was not a particular issue, and the concept of servers constantly updating each other had not been developed. I have to say I was never totally convinced of the arguments against the "on-change" concept. I think you have described a practical solution to the problem. Vivian ------------------------------------------------------------------------- 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
