Oliver Schröder
2017-06-14 18:18:26 UTC
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
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