--- 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
