Anders Gidenstam wrote > 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. >
Way back in the early iterations of MP we had 2 sorts of messages - those which were transmitted on every cycle, and those which were transmitted on change of data. The trouble with that is with clients joining and leaving, it is hard to ensure that the clients are up-to-date. So you need to re- transmit on clients joining, which means triggering the originating client etc. etc. I think for that reason it was abandoned. It's just easier and more reliable to transmit everything all the time. And actually, the end result in data transmitted terms turns out to be not that different. Vivian ------------------------------------------------------------------------------ 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
