On Friday 09 October 2009 00:21:11 James Turner wrote: > > On 8 Oct 2009, at 23:05, Vivian Meazza wrote: > > > This, or something very like it, is a long outstanding proposal that > > never > > quite made it. No one got a round tuit for it I guess. That said, a > > minute > > delay on event-driven properties is probably too much. > > Well if it's 30 seconds, I think a 30 seconds 'synchronising state > with MP server' would be fine for most people - especially if it > happens in parallel with scenery loading. If it's more like two > minutes, then it certainly needs some thought, but I'd rather have a > slightly sub-optimal UX for this case, but support event-drive props. > (Especially if I want to centralise ATIS / active runways / navaid > idents in the future, as John Denker has suggested before) > > Another option is for the MP server to cache all the props from each > client, and allow clients to request a 'burst' of the cached state > right after they connect, but before the normal updates start. I don't > know how the MP server->server tieing is implemented, but I suspect > such a cache would also be valuable in proxying event-driven props > between servers.
I'm actually working on a new MP-protocol. But since fgms is a one-man-show and my spare time is very limit, progress is very slow. What I have done so far: - handle UDP-traffic as a stream. Every client maintaines a receive-queue and a send-queue. The overlying process (fgms,fgfs) can simply read or write from/to clients as if it is a standard stream. - The server maintains a list of clients. Every client has a property tree, filled with values read over MP-protocol - The data sent over MP-protocol is defined in a property-xml-file, with additional attributes defining when to send (on change, evertime, once) - authentication between client and server Currently I'm trying to get everything working. I therefor I have written a pseudo client, called mpdummy. The code is currently not fully functional, as it is work in progress. I try my best to write some documentation of the current state over this weekend and put the current development version of fgms into cvs (the code currently in fgms-cvs is very outdated). For the curious reader: You can find some information about the protocol and code under: http://fgms.sourceforge.net/protocol/ (library documentation) and http://fgms.sourceforge.net/protocol.php (description about the protocol) But keep in mind that this information is not cutting edge. Cheers, Oliver ------------------------------------------------------------------------------ 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
