On 25/12/2015 02:36, Laurie, VK3AMA wrote:
On 25/12/2015 7:52 AM, Bill Somerville wrote:
Hi Laurie,
as I said we do not check for redundant status updates. I will have a
scan through the code and see if any can be easily eliminated but
checking for every field against previous values may be quite tricky.
WSJT-X is largely event driven and redundant events happen all the
time because of the way that GUI event loop messages are generated.
73
Bill
G4WJS.
Bill,
Comparing identically running instances, one 1.5.0 and the other
1.6.0. The 1.6.0 status packet is 2 bytes longer than 1.5.0
These two packets send @ 50 secs differ by only the last byte. This
byte is a one (1) on the first packet and a zero (0) on the second
packet. This suggested a boolean flag of some sort. Indicating a
possible schema change.
Examining the header of each packet (MagicNo + Schema + MessageType +
ID(rig-name)) shows a schema value of 2 for both 1.5.0 and the 1.6.0
despite the 1.6.0 difference.
Examining the NetworkMessage.hpp file for 1.6.0 shows that the Schema
is now 3, but is *incorrectly* reported in the UDP packets as 2. <--
this is why I didn't pickup on the schema change in my programs.
The two status packets @ 50 secs correspond to the new status flag
indicating that WSJT-X has started decoding and finished decoding. Now
I know and understand the purpose of those two packets.
After all this, the only defect I can see is an incorrect schema
reported in each UDP packet. 2 instead of 3.
de Laurie VK3AMA
Hi Laurie & all others writing WSJT-X UDP message applications,
here is a summary of how users of the WSJT-X UDP protocol should handle
schema numbers and message content:
The first thing to note is that each message may be extended with new
fields over time. It is only guaranteed that the content of fields
defined at any particular time will not change in later revisions. That
does not mean that the number of fields or the consequent length of the
messages is fixed. So the user of the messages can read the fields that
they understand but they must not assume the overall length. Any data
after the last field expected should be ignored and missing fields
should be substituted with a default value. This possibility of
extensions to messages is nothing to do with the schema number. Users of
the message protocol simply unpack the fields they need and use them as
the see fit. The only use of the message length must be to stop
unpacking fields if the end of the message is reached. When sending back
messages they pack the fields that they wish to send according to the
message definitions in NetworkMessage.hpp, the message handling code in
WSJT-X will deal with short messages in a reasonable way (and oversize
messages). Overall this means that clients and servers need not be built
against the same version, this is a necessity as we cannot expect all
users of cooperating tools to upgrade in lock step nor indeed expect all
cooperating application developers to release new versions in lock step.
Note that new fields (and messages) can be added without updating the
schema number, the purpose of the schema number is not to specify the
number or meaning of fields, it is there to support new generations of
the Qt data type encoding of the binary data that underlies the message
fields. So for example if the Qt team find it necessary to change the
way that a date field is encoded then they would update their schema
version, in parallel with that we would have to increment our schema
number so that users of the UDP messages would know that which data type
encoding scheme were in use. We will only increment the schema number if
the underlying encoding of a data type we use changes, with one
exception detailed below. This implies that the schema number will not
change frequently, in fact it may never change since I doubt that the
data types currently used will change encoding.
The one exception is that in WSJT-X v1.6.0 the schema number has been
incremented to three, this change was to introduce the mechanism for
schema number negotiation. It was done to elicit exactly this response
from UDP message users ;) You are the first to notice so far. The
negotiation process goes as follows:
Heartbeat messages contain a maximum schema number supported field which
is the highest schema number that the sender is able to support. The
first message sent back should be sent with the minimum of the senders
supported schema number and the maximum supported by the receiver.
That's about it really, all that is required is that once you have sent
that first message you must stick to no higher than the encoding schema
you choose to negotiate. WSJT-X will restrict its maximum schema based
on the schema of the messages it receives. Here is a typical exchange:
WSJT-X sends a heartbeat message with a maximum schema #4
A cooperating application only knows about schema #3 so it replies with
schema #3 and schema #3 encodings.
WSJT-X downgrades to schema #3 for further messages.
There is one subtly that must be catered for, the WSJT-X UDP protocol is
a many to many topology and at any time a new application may join the
network that only supports a schema number lower than the currently
negotiated one. When this application negotiates the new schema with
WSJT-X the schema number for all outgoing messages will be lowered.
Therefore all messages must be examined for schema number and if it is
lower than the negotiated schema number then the receiving application
must adapt its schema for unpacking that and subsequent messages. WSJT-X
does not maintain a supported schema number on a server by server basis,
it communicates to all with the minimum schema number of all servers
that have negotiated so far. There is no mechanism to reverting to
higher schema numbers short of restarting all applications.
Summary of schema numbers:
Schema #1 used a broken Qt encoding Qt_5_0 so message applications
should not use schema #1,
schema #2 is used in WSJT-X v1.5 and uses the Qt_5_2 encoding,
schema #3 is used in WSJT-X v1.6 and uses the Qt_5_4 encoding.
Note that none of the data types used by the UDP message protocol have
different encodings between schema #2 (Qt_5_2) and schema #3 (Qt_5_4),
the increment was simply to introduce the schema negotiation process.
73
Bill
G4WJS.
------------------------------------------------------------------------------
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
