presence of messages is reported on connect (as are bad relayIDs).
Now a game with a robot player in a "closed" game can continue. Once
the next set of linux-side chances is committed.
manage a single connection to the relay for all of its games. Works
so far to the extent that the game's playable with all boards on the
same device (with checkins about to come) as long as all boards are
open. (Client doesn't handle opening closed games yet.)
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.
of which is TBD). When a new-version client connects, store the value
it's passed. At first this will let me track how quickly people
upgrade. Later I can use it to let different clients have different
formats to their messages e.g. to proxy.
remove the artificial limit on number of stored messages. This seems
to fix problems where lots of chats in a row clog up the relay so that
messages never get flowing again. Works more cleanly than
artificially ACKing.
recycling of crefs between when devices in a game connect. This plus
movement of messages into the DB will re-enable games played without
the two devices ever being connected at the same time.