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.
reconnect. I was putting both (i.e. the same device twice) in the
same game. Now I detect this based on the seed being duplicated and
treat the device as having failed to ACK then proceed with the CONNECT
as if it were new. Tested pretty heavily but only with two-device
games.
(including seed so it's harder to spoof); respond to that by setting a
DEAD column in the db and flagging the device as gone. Notify any
connected device of the fact. Refuse to accept new connections to
that game. As already-connected devices reconnect, allow them to do
so but send a new status message that their game is dead. Not heavily
tested yet.
connName/hid pair. This works around a problem where a device,
continuing to connect and send all pending messages for another device
that is not connecting, winds up with hundreds of identical messages
stored.
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.
threads can't share the same db connection. So synchronize all
queries. Multiple threads *can* access the db concurrently as long as
each has its own connection, so I could add connections to the tpool
threads. But this will probably be performant enough for the first
10K simultaneous users. :-)
ALLCOND until it's time to kill the cref. When one device connects
and leaves the cref is recycled, so when a new device joins and is
assigned the same game and a new cref is initialized the number of
players already registered must be set from the db entry; do that.
consistent: nJoined in DB tracks players "ever seen and issued
connName" rather than "currently connected". Next step: debug game
between two devices never connected at same time.
simplify things by using a db to survive a crash/reboot. So far (with
next checkin) manages to update a db. Next need to do queries instead
of searches through in-memory data.
