I want receiver to know when message was originally created. This adds
timestamp to messages and passes it via send proc. Client needs to
send it where possible. So far, MQTT format can't include it without
change, so I'm adding a new proto version. This change can read the
new version. Once that's well-enough distributed I can start sending
using it. Other transmission types than MQTT are for later.
Attempting to stop calling the relay, but to let relay-only games finish
and issue invitations. Big changes are that relay is removed from games
if they have viable mqtt connections, and relay timers fire less often,
then eventually stop getting set if there are no active games. Result is
that a relay-only invitation won't likely be received, but there should
be few or none of those now.
augmentAddrIntrnl() sets the has-mqtt bit in comms->addr but not the
address data (has none). If that address had been loaded from stream
the address bits will be random, not 0, and so get treated as an
address.
Sending in 32 bits what can probably fit in 8 -- twice -- is dumb. As is
sending the gameID (as connID) when it's already known. In 2016 I added
a fixed marker, so I can count on all current code sending that. If I
fail to find that, I know the sender is new (current release or better.)
In that case, use 12 bits instead of 32 for two fields, drop the marker
and the connID. Result is that an ACK's size, including MQTT headers,
drops from 28 bytes to 21.
It's simpler this way, and I'm tired of stuff not happening because the
OS chooses not to schedule e.g. an invitation send for minutes. Goal's
to be running BluetoothServerSocket.accept() as much as possible when
there are active BT games in play OR when the game's in the foreground.
If that's happening, sent invitations and moves will be received when
users expect. When there's no traffic and app isn't being brought to
foreground, backoff will ensure I don't try to run accept() too often.
FWIW, BTLE seems to offer a better way to do this (to have an app be
responsive to incoming invitations when it hasn't run in the foreground
in a while), but it requires users to accept FINE_LOCATION
permission. I'm hoping I can make this work to avoid asking for that
permission.
Not at all tested, but now the game's timestamp is kept and passed in to
where it can be used to determine, e.g., which of two Bluetooth device
names to keep for a given opponent.
Got as far as having gtk client display list of previously harvested
known players to be invited. Their addresses, or at least mqtt ids are
saved. Next is to actually invite one.
I'm fixing android client not showing stats for or allowing to disable
mqtt after it's added automatically to a game that connects
otherwise. Problem was that only the channel got the mqtt address
flag. So now add the flag for any type that's added.
If a configured-as-host game joined an existing game the relay would
make it a guest. The android util_ callback for that change was only
implemented in BoardDelegate and so the change was dropped unless the
game was open/visible. Because comms recorded the change, though, the
callback would never be called again and so the game never learned to
behave as a guest and never registered: permanent failure to join game!
Implemented with a new server state so initClientConnection can be
called from server_do() instead of inside comms while processing an
incoming packet.
To avoid inviteless relay games not having an mqtt channel (and so
yielding a crappy experience) pass the mqtt devid when device registers
and when server replies with all-here.
This is meant to replace the relay eventually, but for now it's a new
option, like BT or SMS, to be chosen. Protocol is handled in common/
code for the first time, meaning that linux and android interact without
the need to keep two platforms in sync. Linux uses lib-mosquitto, and
Android uses eclipse's Paho client (the generic java version, not the
one that uses four-year-old Service patterns and so crashes for SDK >=
26.)
I was getting an occasional crash using a stale env to delete a dict's
resources because the dict was cacheing the env that created it. Dumb!
Using the thread->env mapping stuff worked, but that felt risky and so I
tried just passing it in. It's safe, and involves an amount of change I
can tolerate. So likely going that way.
