Discussion:
new FGMS release v0.13.1
(too old to reply)
Oliver Schröder
2017-06-14 18:18:26 UTC
Permalink
Hi,

I have just released version 0.13.1 of fgms, which includes some new
features:


[NEW] honour client provided radar range

The value provided is evaluated by fgms. The client will receive traffic
of other clients which are within this range (so it's a receiver range,
not a sender range).
This range can change over time, so clients are free to adjust the value
depending on whatever they like (eg. their altitude).


[NEW] Serverside configurable value of MaxRadarRange, default 2000 nm

To suppress the ability to receive traffic of all connected clients,
I've implemented a maximum value for the radar range which defaults to
2000 nm (but can be configured in fgms's config file). 2000nm is
arbitrary, but I assume it's a usable default.


[FIX] fgms only checks major version of client protocol.

I strongly recommend to increase the minor version if
the protocol has changed at all, increase the major version
if the new version is incompatible to previous versions

[NEW] Ping Packets

fgms will respond to ping packets (MsgID 9) and will only check the
following header fields: Magic, Version, MsgId (obviously :) and MsgLen.
It will modify only MsgID (set to 10) and send the packet back to it's
sender. Neither ping nor pong messages will get forwarded in any way and
fgms will not respond to pong messages. So it's up to fgfs and other
clients to make something out of it.


Other changes are fgms internal, or the complete list see ChangeLog of fgms.

While talking about MsgIDs, here is my current list of defined message
types:

typedef enum
{
//@{ deprecated message ids
U1 = 1, // old CHAT_MSG_ID
U2, // old pos data
U3, // old pos data,
U4, // old pos data,
U5, // old pos data,
U6, // RESET_DATA_ID
//@}
/// a "position" message, and the most trafficked
POS_DATA,
MP_2017_DATA_ID,
/// a ping packet is send verbatim back to sender
PING, // request
PONG, // answer
} MSG_ID;

My plan regarding IDs is to revive ID 1 for messages targeted at clients
and originating from the server. fgfs still "understands" those
messages, even though it displays them annoyingly only on the terminal
(but thats a fight for another day).
A few more IDs will be used for inter-server communication. I will use
U2-U6 for them (I'm not yet sure how many I will need).


I also have update the mpstatus page
(http://mpmap01.flightgear.org/mpstatus/) where you can see which
servers are already updated. While looking at the list of servers I also
recognised mpserver04 and mpserver13 are down, as it seems for some time
already. I have no knowledge of their state but guess they just
transformed into vapor servers...

However, I have some plans for the near future ragarding fgms:

1) the source repository will move back to sourceforge. That will be
done first in the next 2 days. I also want to use the mailing lists
provided by sf and already created two of them: fgms-devel and
fgms-announce. The latter will be used to announce new releases of fgms,
the first of (only) fgms-related development. So feel free to subscribe.

2) bury fgms-1.x and
3) bring features of fgms-1.x slowly into fgms-0.x and let evolve the
protocol together with fgfs.

4) The first thing will be the list server, which automates server
management and will eliminate the problem of new and vanishing servers.

5) After that I will implement an authentication service for flightgear,
which will also make changes to fgfs necessary. There are still
questions regarding this (e.g. how we transmit passwords, in what extend
do we want authorisation etc.). I expect quite some discussion about this.

While 1) - 3) will be done in the next days, 4) and 5) will keep me busy
for the next weeks.

Best wishes,
Oliver
James Turner
2017-06-14 21:53:49 UTC
Permalink
Post by Oliver Schröder
I have just released version 0.13.1 of fgms, which includes some new
Thanks Oliver, these sounds like big improvements to me!

Kind regards,
James
Michael
2017-06-17 09:46:01 UTC
Permalink
Hi,

First, thank you for the recent progress on MP and FGMS.


I have just released version 0.13.1 of fgms,


A few servers have updated straight away. But as soon as they did, no
client connecting would get any traffic back, though they were all showing
as connected on the live maps. I think this was true even for new 2017.2
FlightGear clients.

I tested and could tell my client was not getting any traffic *packet* at
Post by Oliver Schröder
[NEW] honour client provided radar range
As hinted in msg 35687340 on this list, I assumed that you used the old
"ReplyAddress" field, and read the range as a packed integer distance in
NM, but I may have missed subsequent spec. Confirm?

If you are reading zeros and did not default to the 100-NM range, of course
we'd get nothing back. But I have tried sending the distance in "ReplyPort"
instead, to no avail. What is the problem?
Post by Oliver Schröder
[NEW] Ping Packets
Cool.
Post by Oliver Schröder
My plan regarding IDs is to revive ID 1 for messages targeted at clients
and originating from the server.
What does "originating from the server" mean here?
Oliver Schröder
2017-06-19 07:37:00 UTC
Permalink
Hi Michael,
Post by Michael
A few servers have updated straight away. But as soon as they did, no
client connecting would get any traffic back, though they were all
showing as connected on the live maps. I think this was true even for
new 2017.2 FlightGear clients.
Implementing new features and "fix" others at the same time is not
always a good idea :-)
Post by Michael
I tested and could tell my client was not getting any traffic *packet*
[NEW] honour client provided radar range
I have introduced a bug at a completly unrelated location. Sorry for
that. It's fixed in 0.13.2
Post by Michael
As hinted in msg 35687340 on this list, I assumed that you used the old
"ReplyAddress" field, and read the range as a packed integer distance in
NM, but I may have missed subsequent spec. Confirm?
Yes, the radar range is extraced from "ReplyAddress". Unfortunatly older
fgms-versions (prior to 0.13.0) did use this field for another purpose.
So I have to play a bit more tricks on this. But it defaults to 100nm
("out_of_reach" configuration item in fgms.conf).
Post by Michael
My plan regarding IDs is to revive ID 1 for messages targeted at clients
and originating from the server.
What does "originating from the server" mean here?
As a server administrator I want to be able, to send messages from my
server to my clients. Something like "server is going down for
maintenance and will be back in 10 minutes". Nothing exciting but (I
think) useful.

Regards,
Oliver
Michael
2017-06-19 07:55:22 UTC
Permalink
Post by Oliver Schröder
Yes, the radar range is extraced from "ReplyAddress". Unfortunatly older
fgms-versions (prior to 0.13.0) did use this field for another purpose.
So I have to play a bit more tricks on this.
Feel free to change it to the port one if it is free and easier. Nobody has
actively been relying on this choice yet. Just make sure you say so soon in
that case.
Richard Harrison
2017-06-19 12:17:34 UTC
Permalink
Post by Oliver Schröder
Post by Michael
"ReplyAddress" field, and read the range as a packed integer distance in
NM, but I may have missed subsequent spec. Confirm?
Yes, the radar range is extraced from "ReplyAddress". Unfortunatly older
fgms-versions (prior to 0.13.0) did use this field for another purpose.
So I have to play a bit more tricks on this. But it defaults to 100nm
("out_of_reach" configuration item in fgms.conf).
I assumed that the field was unused. Is this something that will work
fine now, or something that could be unreliable. If this is going to
compromise the protocol then lets discuss possible other solutions -
it's not too late to issue another 2017.2 release and I'd rather get it
right.
Oliver Schröder
2017-06-19 12:42:40 UTC
Permalink
Hi Richard,
Post by Richard Harrison
Post by Oliver Schröder
Post by Michael
"ReplyAddress" field, and read the range as a packed integer distance in
NM, but I may have missed subsequent spec. Confirm?
Yes, the radar range is extraced from "ReplyAddress". Unfortunatly older
fgms-versions (prior to 0.13.0) did use this field for another purpose.
So I have to play a bit more tricks on this. But it defaults to 100nm
("out_of_reach" configuration item in fgms.conf).
I assumed that the field was unused. Is this something that will work
fine now, or something that could be unreliable. If this is going to
compromise the protocol then lets discuss possible other solutions -
it's not too late to issue another 2017.2 release and I'd rather get it
right.
Everything should be fine already. I've removed the code in fgms which
used this field (in version 0.13.0) and introduced code which copes
older servers.
The good thing about the current implementation is, that I do not need
to parse the complete packet and look for a "radar range" property.
While this may be the cleaner way to do it, I believe that the current
way properties are encoded is not the way we should encode them. The
problem with the current implementation is, that all clients (and
servers) must know what id maps to what property. So if somebody
introduces new properties (like radar range in this case), all parts
must be updated even if they are not interrested in this property. A
better approach would be, if the type of the property can be derived
from its ID, so application can ignore them in a save manner and jump to
the next property. But that's a fight for another day...

As mentioned, the current code should just work out fine. But of course
it is untested and may still contain some errors. We need to test this.

Best regards,
Oliver
Richard Harrison
2017-06-19 14:42:44 UTC
Permalink
Post by Oliver Schröder
Everything should be fine already. I've removed the code in fgms which
Thanks for confirming this.
Post by Oliver Schröder
The good thing about the current implementation is, that I do not need
to parse the complete packet and look for a "radar range" property.
The visible range and radar range are different IMO - so I wanted to
separate them out; and in this case it seemed sensible to put it in the
header.
Post by Oliver Schröder
introduces new properties (like radar range in this case), all parts
must be updated even if they are not interrested in this property. A
This is what the partitioning scheme is designed to achieve, albeit in a
different way.

FG partitions the message into chunks so that the new properties are
sent at the end. This gives us a future proof way of adding properties
because the moment a client hits an unknown ID it can stop processing -
because all that follows any unknown ID will also be unknown.

I looked at including some sort of type info the field; and concluded
that it was probably going to be too complicated to get working with the
rest of the 2017.2 - it would reduce the index space (because of short
ints) to 16384 - and came to the conclusion that the partitioned
approach solves the problem in a better way (in terms of FG, not sure
above other clients).
Oliver Schröder
2017-06-19 17:43:02 UTC
Permalink
Post by Richard Harrison
Post by Oliver Schröder
The good thing about the current implementation is, that I do not need
to parse the complete packet and look for a "radar range" property.
The visible range and radar range are different IMO - so I wanted to
separate them out; and in this case it seemed sensible to put it in the
header.
I guess you are right. But visibility has to be managed within
flightgear (or other clients, if there are any other than pure radar
clients).

IMHO, there is a third range for radio transmissions.
Post by Richard Harrison
Post by Oliver Schröder
introduces new properties (like radar range in this case), all parts
must be updated even if they are not interrested in this property. A
This is what the partitioning scheme is designed to achieve, albeit in a
different way.
[...]
I see what you mean, and really appriciate the things you did already. I
just suggest thinking about putting properties in a special property
packet, which only has a minimalistic header (to be defined), and
ID|Property values using the scetched scheme of IDs.

But I also suggest to leave it for another day (which will give me a few
days implementing other things first) and discuss this in a thread of
its own.

Best wishes,
Oliver

Loading...