Conflicts:
xwords4/android/XWords4/src/org/eehouse/android/xw4/DlgDelegate.java
xwords4/common/comms.c
xwords4/linux/cursesmain.c
xwords4/linux/cursesmain.h
xwords4/linux/gtkmain.c
xwords4/linux/gtkmain.h
xwords4/linux/linuxmain.c
xwords4/linux/main.h
xwords4/linux/scripts/discon_ok2.sh
xwords4/relay/xwrelay.cpp
(Note: The curses app crashes on exit with mempool assertions, but that's a problem before the merge.)
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.
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.
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.)
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.
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.
