devid you tossed your relayID and reregistered. Which meant any
existing messages meant for your relayID were orphaned, and any open
games didn't know who they belonged to until you reconnected to them
with your new relayID. So: modify the UDP protocol (though not on
Android yet) to include both relayID and devid with registration, with
one or the other an empty string if not present or not changed from
earlier. I can't fix existing clients that are dropping their
relayIDs, but when one does a re-connect without a relayID I can look
it up from the existing game record, then reuse it rather than issue a
new one. Better than nothing -- and that protocol will be obsolete
soon anyway.
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.)
