The two weeks is configurable. But the idea is somebody creates a game
with a random name but it's never joined. Eventually the name is used
again and the first to connect joins the existing game that will never
progress. I could just prune from the DB, but this is less work ongoing.
Stuff I'm doing with invitation resends is making the relay loop
inifintely. Let's assert a small loop count instead: better to crash and
restart than loop forever unable to process requests.
When a device reconnects and there's no record for its
game (e.g. because an ISP's screwed up and the db and its host are
lost), recreate but keep the device's hid (position in the arrays
indicating mostly whether it's the inviter or invitee.) Tested by
running the linux scripts and deleting the games table mid-way
through, but not yet tested with android devices.
and their slots are empty or have been reassigned: basically we check
if a device goes where it expects, and if not treat it as a new
connection rather than a reconnect, meaning its hostid may change.
Existing device code seems ok with that -- and at any rate I don't
think ACKs get dropped much in the wild.
once UDP sockets and/or per-device (not per-game) connections come
along. Lots of changes, most not involving code flow but a couple
that did. So far two gtk games can connect and exchange moves.
Haven't tested reconnection or store-and-forward.
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.
duplicating set of sockets owned by a cref, moving it from cinfo into
cref and caching a copy outside when cref is unclaimed (after which no
change is possible until it's claimed again.)
that cid, then by the time we can claim it there's no longer space for
us. Call new method after the claim succeeds to make sure there's
still room, and if not relinquish and loop back to the DB for another
try.
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.
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.
HostRec. This fixes failure to reconnect so that now a complete game
is possible (gtk version) without the two devices every being
connected at the same time.
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.