Re: [Flightgear-devel] Exposing a property over MP

2009-10-10 Thread Mathias Fröhlich

Hi,

On Thursday 08 October 2009 22:09:40 Martin Spott wrote:
> If bandwidth is not a matter, then you'd probably want to jump on the
> HLA train and join the CERTI/VirtualAir effort. They're offering
> everything like subscribing to attributes and the such   yet I have
> to state that reduced bandwidth footprint, compared to the current
> state, would be beneficial to have in CERTI  ;-)
... currently working on fixing usability stuff in certi. So stay tuned :)
Anyway, I also consider an RTI a possible multiplayer replacement.
Even if we would handle local RTI federations different than internet wide 
stuff. But yes, an RTI provides almost all we would need to get that right.

Greetings

Mathias

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


Re: [Flightgear-devel] Exposing a property over MP

2009-10-10 Thread Mathias Fröhlich

Hi,

On Thursday 08 October 2009 17:29:21 James Turner wrote:
> Related to the new route-manager: I could very easily define a string
> property which contains a plain text summary of the filed flight-plan.
> What is the magic required to expose that string (which be 200 or 400
> bytes, I guess, depending on how many waypoints are in the route) over
> MP, so that the ATC 'aircraft' could see them?
> 
> Is there an 'event' channel in MP, to deal with properties which
> change infrequently? (Compared to position/velocity/surface positions/
> etc)

No, the current implementation just dumps all.
If you want to do that in a reliable way with a minimum of transferred data 
you will need a bunch of changes to the protocol and the server.

The easiest way would be to have some fields not updated on each cycle but just 
update only about every few seconds. Make sure that you add some randomness to 
the count that we avoid bursts to the communication of those values.

Greetings

Mathias

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


Re: [Flightgear-devel] Exposing a property over MP

2009-10-09 Thread Martin Spott
Erik Hofman wrote:

> I once played with the idea of assigning 32-bit id's to property names 
> (and make the unique and consistent across clients) and a simple push 
> and pull protocol.

As an interesting side effect, assigning pre-defined ID's to every
property would require all involved aircraft to comply with a common
property-subset instead of everyone defining their favourite ones at
will  ;-)

Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

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


Re: [Flightgear-devel] Exposing a property over MP

2009-10-09 Thread Oliver Schroeder
On Friday 09 October 2009 14:47:14 Vivian Meazza wrote:
>  
> This all sounds very exciting. I'm usually available for testing (on
> Windows) - remember the hassle we had with linux/Windows and MP in the past?

We will not get into such trouble again. But... ;)

I have ripped all plib networking code from the multiplayer part and replaced 
the code by a new library (which will be shared between fgfs and fgms). We 
have to make sure, that this library works on all supported plattforms.

As stated in my previous mail, I'll try to get the code into my cvs over the 
weekend and we can start test compiling on different plattforms.


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


Re: [Flightgear-devel] Exposing a property over MP

2009-10-09 Thread Vivian Meazza
Oliver Schroeder wrote:

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

 
This all sounds very exciting. I'm usually available for testing (on
Windows) - remember the hassle we had with linux/Windows and MP in the past?

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


Re: [Flightgear-devel] Exposing a property over MP

2009-10-09 Thread Erik Hofman
James Turner wrote:
> There's quite a lot of improvements that could be made to higher  
> levels of MP, if arbitrary properties could be synchronised over MP :)

I once played with the idea of assigning 32-bit id's to property names 
(and make the unique and consistent across clients) and a simple push 
and pull protocol. I never materialized though (although I did point out 
a link to the code when the MP discussion started).

Erik

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


Re: [Flightgear-devel] Exposing a property over MP

2009-10-09 Thread James Turner

On 9 Oct 2009, at 07:30, Oliver Schroeder wrote:

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

Sounds fantastic, let me know if you'd like comments on the code or  
help with testing.

Regards,
James


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


Re: [Flightgear-devel] Exposing a property over MP

2009-10-08 Thread Oliver Schroeder
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


Re: [Flightgear-devel] Exposing a property over MP

2009-10-08 Thread James Turner

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.



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


Re: [Flightgear-devel] Exposing a property over MP

2009-10-08 Thread Vivian Meazza
James wrote

> -Original Message-
> From: James Turner [mailto:zakal...@mac.com]
> Sent: 08 October 2009 22:06
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] Exposing a property over MP
> 
> 
> On 8 Oct 2009, at 21:54, Anders Gidenstam wrote:
> 
> > Going in that direction could be a feasible way to
> > reduce the bandwidth consumption, though.
> 
> One other observation - there's several unused SGProperty flags
> (besides ARCHIVABLE) - it might make sense to add a 'shared' or
> 'published' flag, to allow properties to opt-in to being sent this
> way. Then the MP code 'just' has to search the tree (or keep an index)
> of such properties, listen for changes to them, and re-send them at
> some low rate (maybe send one in each regular packet, so it might take
> a minute to receive them all...)
> 
> 

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.

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


Re: [Flightgear-devel] Exposing a property over MP

2009-10-08 Thread James Turner

On 8 Oct 2009, at 21:54, Anders Gidenstam wrote:

> Going in that direction could be a feasible way to
> reduce the bandwidth consumption, though.

One other observation - there's several unused SGProperty flags  
(besides ARCHIVABLE) - it might make sense to add a 'shared' or  
'published' flag, to allow properties to opt-in to being sent this  
way. Then the MP code 'just' has to search the tree (or keep an index)  
of such properties, listen for changes to them, and re-send them at  
some low rate (maybe send one in each regular packet, so it might take  
a minute to receive them all...)



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


Re: [Flightgear-devel] Exposing a property over MP

2009-10-08 Thread Anders Gidenstam
On Thu, 8 Oct 2009, Vivian Meazza wrote:

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

Yes, that is one issue. The approach I aimed for the last time I tried to 
mess with the MP subsystem was to send properties on change (perhaps 
repeated Y times) and every X seconds (to update newly joined users and 
cover lost packets). That seemed to be simple enough that it could even 
be backwards compatible - but unfortunately it caused occasional failures 
in the property interpolation code on the receiving side that I didn't 
manage to sort out. Going in that direction could be a feasible way to 
reduce the bandwidth consumption, though.

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


Re: [Flightgear-devel] Exposing a property over MP

2009-10-08 Thread James Turner

On 8 Oct 2009, at 21:37, Vivian Meazza wrote:

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

Easier certainly - but I think that was a bad tradeoff in the longer  
term.

Sure, new clients will need to do more synchronize state, but  
potentially a lot of infrequently changing data can be removed from  
the regular updates, making them smaller too - while allowing, as  
everyone seems to agree, richer and easier MP interaction.

As simple as possible is a good motto, but the current system seems a  
bit too simple. Of course, it does work - and I've got enough other FG  
projects that someone else can worry about this, for the moment. I'd  
be happy to share what I know about mixed reliable/best-effort real  
time networking, but it's not exactly much :)



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


Re: [Flightgear-devel] Exposing a property over MP

2009-10-08 Thread Vivian Meazza
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


Re: [Flightgear-devel] Exposing a property over MP

2009-10-08 Thread Martin Spott
James Turner wrote:

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

As far as _I_ remember, the current state of the protocol was _not_
designed for having everyone dump arbitrary data to the crowd but
instead to allow for synchronization of positions, velocities and
accelerations at reduced latency even over low-bandwidth lines. The
current MP protocol is probably not perfect, but I think it still does
quite a good job at its intended purpose. I remember running MP over a
64 kBit's ISDN line at satisfactory performance.

If bandwidth is not a matter, then you'd probably want to jump on the
HLA train and join the CERTI/VirtualAir effort. They're offering
everything like subscribing to attributes and the such   yet I have
to state that reduced bandwidth footprint, compared to the current
state, would be beneficial to have in CERTI  ;-)

Cheers,
Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

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


Re: [Flightgear-devel] Exposing a property over MP

2009-10-08 Thread Anders Gidenstam
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


Re: [Flightgear-devel] Exposing a property over MP

2009-10-08 Thread Jacob Burbach
> The way the MP protocol is done now you really really do not want to do
> that by creating a new MP enabled string property and put the flight-plan
> in it. Not only is the string encoding horribly inefficient (a 32bit word
> per character) but it would also be sent in each and every packet.
Wow, that's really bad, why are strings being encoded with 32 bits per
character exactly?

--Jacob

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


Re: [Flightgear-devel] Exposing a property over MP

2009-10-08 Thread James Turner

On 8 Oct 2009, at 18:08, Anders Gidenstam wrote:

> The way the MP protocol is done now you really really do not want to  
> do
> that by creating a new MP enabled string property and put the flight- 
> plan
> in it. Not only is the string encoding horribly inefficient (a 32bit  
> word
> per character) but it would also be sent in each and every packet.

That sounds bad :)

>
>> Is there an 'event' channel in MP, to deal with properties which
>> change infrequently? (Compared to position/velocity/surface  
>> positions/
>> etc)
>
> No, there isn't but this might be time to create one. There is a
> rather complicated Nasal module for that kind of communication in
> Nasal/mp_broadcast.nas which utilizes a MP enabled string property  
> (but
> send the relatively short empty string, "", when nothing is going on.

Eurgh, that sounds bad too.

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.

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

Regards,
James


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


Re: [Flightgear-devel] Exposing a property over MP

2009-10-08 Thread Anders Gidenstam
On Thu, 8 Oct 2009, James Turner wrote:

> Related to the new route-manager: I could very easily define a string
> property which contains a plain text summary of the filed flight-plan.
> What is the magic required to expose that string (which be 200 or 400
> bytes, I guess, depending on how many waypoints are in the route) over
> MP, so that the ATC 'aircraft' could see them?

The way the MP protocol is done now you really really do not want to do 
that by creating a new MP enabled string property and put the flight-plan 
in it. Not only is the string encoding horribly inefficient (a 32bit word 
per character) but it would also be sent in each and every packet.

> Is there an 'event' channel in MP, to deal with properties which
> change infrequently? (Compared to position/velocity/surface positions/
> etc)

No, there isn't but this might be time to create one. There is a 
rather complicated Nasal module for that kind of communication in 
Nasal/mp_broadcast.nas which utilizes a MP enabled string property (but 
send the relatively short empty string, "", when nothing is going on.

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


[Flightgear-devel] Exposing a property over MP

2009-10-08 Thread James Turner
Related to the new route-manager: I could very easily define a string  
property which contains a plain text summary of the filed flight-plan.  
What is the magic required to expose that string (which be 200 or 400  
bytes, I guess, depending on how many waypoints are in the route) over  
MP, so that the ATC 'aircraft' could see them?

Is there an 'event' channel in MP, to deal with properties which  
change infrequently? (Compared to position/velocity/surface positions/ 
etc)

Regards,
James

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