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
