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=100url=/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
