On Thu, 8 Oct 2009, James Turner wrote:

>
> That sounds bad :)

It is, but in my experience there is no core developer feeling 
particularly responsible for the MP subsystem - most of the few patches 
that has been submitted in the past years have disappeared into the 
mailing list archive without (re)action.

> Eurgh, that sounds bad too.

Well, it isn't ideal but it works for my purposes - without breaking MP 
compatibility and without me having to spend a large effort on developing 
something reasonable and more complete and then try for ages to get it 
committed to the code. These days I don't have time to do significant 
development, anyway, with work + commuting taking about 12 hours out of 
every day.

> The 'usual' way to handle this would be to interleave the current
> update packets with 'event' packets, for properties that change more
> slowly. Using a sequence number for each event packet, and using the
> regular update packets to send the current sequence number, it's
> possible to make the event packet delivery reliable - without
> incurring the overhead (or complexity) of TCP.

Well, I would rather try to reduce what we send and mostly only send 
property values when they have changed. Currently every packet contains 
all (active) MP enabled properties - and many of them are constant or 
change very seldom. In that model a string property that rarely changes 
would not be a huge problem.

Perhaps some type of publish-subscribe model could also be useful - so the 
receivers only receive the properties they care about (usually position 
and velocities and those driving external animations if within visual 
distance).

Of course, this adds up to a rather sophisticated protocol so if some 
suitable existing middleware could be found that might be more preferable 
than trying to go our own way (certainly if one considers the current 
level of activity in this area:).

> There's quite a lot of improvements that could be made to higher
> levels of MP, if arbitrary properties could be synchronised over MP :)

Yes, indeed.

Cheers,

Anders
-- 
---------------------------------------------------------------------------
Anders Gidenstam
WWW: http://www.gidenstam.org/FlightGear/

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Reply via email to