There was some confusion around host and self addresses, where they're
created, default values, removing conTypes from defaults that are not
in received host addr, etc. I left in some asserts to help understand
if code that seems wrong but hard to fix is still getting called.
Current networking, based on invitations rather than a relay that
plays matchmaker, allows host to know its address when a game is
created, and for guest to know its host's address in
addition. Enforcing this makes inviting and rematching in common
code (coming soon) easier. Big change on Android is I used to create a
new game prior to passing it to GameConfigDelegate, but now I have to
wait for user to configure (including choosing how to communicate)
before I can create it.
I was getting language name and iso code confused so adding a new type
to keep them separate. Keep string type for crossing JNI boundary and
passing as param e.g. in URLs and Bundles.
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.
Now we use only ISOCode string internally to identify languages, and
since that's universal it can be built into an wordlist and used
without the build of CrossWords knowing about that language
specifically (though it'll have to know about it to have the language
name be localizable.) For legacy support, though, the old int codes
are transmitted in invitations and URLs IFF available, otherwise the
string's used. If a newer build invites and older build to play in a
too-new language there will be trouble.
The old API required passing dict into game creation/loading. New
doesn't, but in some places I was doing other stuff there (like checking
existance), so can't remove there. Still code goes away.
Once in the archive games don't ever send unless opened explicitly (no
resend-all-on-gained-network stuff for them). So don't offer to put a
game there if it has unsent (unacked) messages. Should prevent problem
of a host being archived before it's managed to send its final move to
all guests.
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.
I have a case where app crashed on launch due to the assert that resend_all()
wasn't being called on a standalone game. That happened because somehow
the game's android-side db entry showed pending packets to send, though the
game type was correct. Fix is to check for game type also, but also to add
a test so comms won't get invoked with a null ptr on release builds.
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.
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.
Noticed the same emulator would always generate the same MQTT id, even
after a factory reset. That's because I was seeding rand() in that
jni *game* init code, not the (called-earlier) init of the whole jni
world. MQTT id generation happens on app launch before any game can be
opened so was using an unseeded rand().
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.
