timestamp set when it's opened. Older copies with the same socket can
be tested against the cannonical copy maintained by tpool and sending
avoided when the timestamp shows the endpoint has likely changed.
Change tpool's list of sockets to a map for faster lookup, and get rid
of similar structure in udpqueue.
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.
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.
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.
existing store-and-forward system. With this checkin a robot-vs-robot
game plays for quite a few moves without either game every loaded into
the foreground (via a BoardActivity instance on Android), with all
moves transmitted as a result of relay checks. One of the games
refuses to open later, however, and there are certainly other bugs.
And I'm not sure what happens when a message sent no-conn (without a
cookie ID) is received in the foreground. But this is progress.
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.)
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.
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.
RECONN or CONN that lists the game as full. This means we get the
all-green icon (or the A in the gtk case) when in a consummated game
rather than only when all devices are actually connected.
message to be sent next time it does. And since the cookieID will
change and should be there already anyway, remove it. (Should remove
the hostID too for the same reason.)
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.
memory. Confirmed that devices can hookup without ever being
connected at the same time and that the messages survive a relay
reboot. No further testing yet.
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.
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.
