Re: [Flightgear-devel] [RFC][patch] Multiplayer bandwidth savings
On Tue, 15 Jul 2008, Stuart Buchanan wrote: > Obviously message loss is a concern for both the full-state message as > well as the change messages. > > Does anyone know much about UDP packet loss scenarios? I know that it > isn't a reliable protocol, but I don't know whether typically a > proportion of packets are lost throughout a messages, or whether UDP > connections are lost completely for a period of time. I don't know either, but there is IMHO very little hope of masking a long interruption so it is better try to deal with loss of a few packets with a not too expensive mechanism. > I think I'd be tempted to let the full-state message handle any lost > change-packets, rather than repeating change messages. For properties > that change regularly, losing a single change packet isn't much of an > issue as another change packet is likely to be generated shortly. For > more rarely changing properties, the full-state message is probably > close enough time-wise. I think repeating it once or twice isn't so bad (remember it is just the changed property that is repeated so it isn't a huge increase in packet size). Some value changes can be time sensitive enough that a 2.5 sec delay is too long. Repeating it four times might be a bit over the top, though :) It might also be worth pointing out that this approach never sends more data than what FlightGear currently does. At worst it sends exactly the same amount (i.e. all active MP enabled properties are included in every packet). > I'd suggest labelling the messages so the full state message is > identifiable, and simply have the receiver ignore any change packets for > an entity until a full-state message is received. From memory, I think > we can do this in a backwards compatible way - as I recall the MP system > ignore messages it doesn't understand. Yes, that is a good idea. Or maybe marking the partial state packets in some way. It might be good to try to keep the door open for the possibility of spreading the full state over more than one packet (in case the set of active MP enabled properties gets really huge for some aircraft :). I'll be using my modified binary when I'm on the multiplayer network from now on - if you notice any odd error messages when I join, please let me know and I'll investigate. The diff again (sans a debug printout I forgot to remove): http://www.gidenstam.org/FlightGear/misc/more-efficient-mp-protocol.diff 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
Re: [Flightgear-devel] [RFC][patch] Multiplayer bandwidth savings
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
Re: [Flightgear-devel] [RFC][patch] Multiplayer bandwidth savings
--- On Tue, 15/7/08, Anders Gidenstam wrote: > 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. This sounds like a very good idea, and one that will help scalability. Obviously message loss is a concern for both the full-state message as well as the change messages. Does anyone know much about UDP packet loss scenarios? I know that it isn't a reliable protocol, but I don't know whether typically a proportion of packets are lost throughout a messages, or whether UDP connections are lost completely for a period of time. I think I'd be tempted to let the full-state message handle any lost change-packets, rather than repeating change messages. For properties that change regularly, losing a single change packet isn't much of an issue as another change packet is likely to be generated shortly. For more rarely changing properties, the full-state message is probably close enough time-wise. > 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). I'd suggest labelling the messages so the full state message is identifiable, and simply have the receiver ignore any change packets for an entity until a full-state message is received. From memory, I think we can do this in a backwards compatible way - as I recall the MP system ignore messages it doesn't understand. -Stuart __ Not happy with your email address?. Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html - 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
[Flightgear-devel] [RFC][patch] Multiplayer bandwidth savings
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
