I didn't understand MQTT at all. Per the docs anyway it only keeps a
message around if its "persist" flag is set, and then it only keeps
the most recent per topic. I expected that when a device connected,
messages would be waiting for it, but that's apparently not true (some
evidence to the contrary.) But having all games on a device share the
same topic means only one message can be waiting. So switch to
including gameID in the topic, subscribing to a wildcard topic and
sending to a different one per game. For now, for legacy purposes,
we'll keep sending to the old per-device topic.
Duplicate messages early on, which happened only in the test script
but could have anywhere, broke connectivity. So don't kill address
records when a duplicate shows up. Dupes only escape message ID
checking early (before channel is established). I used to remove
address records when a message was rejected, but don't understand why
so removed that, though asserts show it's not mattering except for
those early messages.
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.
I'm heading toward being able to know what all the games are by how
they're stored in a xplatform way. This is a start. Adding a second key
to storage, and looking at grouping everything where one key or the
other matches.
Thanks to my use of unseeded() rand() early on to generate mqtt device
IDs, a handful of devices are using the same devIDs. The server notices
this and passes a new response which triggers generating a new id that
should be unique (rand() being seeded earlier now.) Testing says the
games that are left behind with the old devid will limp along thanks to
their relay connection while newer games will be better.
Supid bug generating keys from __FILE__ meant each release
build (usually done in /tmp/$$, or on a travis server) had a new key and
generated a new MQTT devID (and other stuff less frequently used.)
Replace the keys with something that won't change, and as a temporary
fix so the upgrade including this fix doesn't generate new keys use the
most recent stored key matching the suffix the old keys will have had in
common.
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.)
Lots of changes adding a games-list view to the app from which you
create new games, open and delete existing ones, etc. There's still
plenty that's unimplemented, but it's already more useful for testing
and development. Which is the point.
I've long wanted common code and state that outlast a single game. The
smsproto stuff is a step in that direction, but this file will be a
place for anything new. Starting, perhaps, with a mapping of deviceID ->
addressInfo (e.g. BT name or SMS number of opponent device) that will
let me stop duplicating that stuff in every game's comms state. We'll
see. It's guarded by a compile-time flag so I can play with in on the
Linux version until ready.
