message over and over when getting updated by GCM. The problem
occurred when one device had an un-ACKable initial message still in
its queue. I call resendAll a lot, which caused that message to get
resent to the other game which then replied without being able to ACK
it so it remained to be sent again. This would continue until users
moved forward in the game. The fix is to add a backoff timer to
resendAll() so that it can't loop. The timer is reset when an ackable
and new message is received, meaning there's been a change in what's
available to resend. And since users calling resendAll manually
expect it to do something, add a force param that ignores the backoff.
seems to fix the problem (but needs a lot of testing.)
ID_TYPE_RELAY id that's not in the devices table (as has happened when
a device switches relay URLs during testing, but might also happen if
I have to delete an entry from the devices table.) In that case,
return ID_TYPE_NONE to the client, which will be its clue to delete
its ID_TYPE_RELAY id and submit the platform-specific id again.
Note: android won't compile this revision thanks to util.h change
which they're communicated to the device. Device is expected to have
a platform-specific notion of ID which the relay stores in a new
devices table and indexes with a 32-bit number which is returned to
the device -- which is encouraged but not required to use it in lieu
of the longer ID in future communications. Modify linux client and
test script to use the relay-supplied id. Some of this is commented
out for now.
dict, give chance to switch, and to download if required. Because of
the way the JNI thread works, and JNI's requirement in general that
env instances match up (e.g. dicts must be destroyed in the same
thread that creates them), substituting into a live game is too hard.
So the game's saved with its new dict and then reloaded.
new param passed to remote and changing final score formatting and
menu items to match. Still need to show old menu on android in case
where game has already ended.
save what it had ACK'd leaving the game permanently broken. Do that
by adding a new method game_saveSucceeded() called after the client
claims to have committed bytes returned by game_writeToStream() to
disk. In that method comms updates the value it'll use in subseqent
ACKs.
