I'm not quite sure why it was firing, but the pattern of a FindGame
failing due to a race condition and requiring a retry exists elsewhere
in the code. Lots of tests pass once this change is made. :-)
The hack I came up with for storing them in memory isn't working. Even
if it's just that I don't understand C++ maps they need to be cleared
when the DB's wiped (my favorite test these days) and I don't want to
spend the time now.
It breaks rematch that "dict" is being passed to the Android client from
the linux side, and this is easier than figuring out how and when to
dereference the link.
Making the right_side elem match its parent height prevents the
lower-right region of game list items from falling through and
triggering a toggle-selection event.
Making the right_side elem match its parent height prevents the
lower-right region of game list items from falling through and
triggering a toggle-selection event.
As expected, moves are no longer received instantly because the UDP
socket isn't available for the relay to write too once the URL
handler (relay.py) finishes.
Ideally the comms module wouldn't go through its connecting routine in
order to join a game. To that end I added a join() method to relay.py
and code to call it. Joins happen (pairing games, starting new ones,
etc.), but after that communication doesn't. First part of fixing that
would be to make cookieID persistent and transmit it back with the rest
of what join sends (since it's used by all the messages currently sent
in a connected state), but I suspect there's more to be done, and even
that requires a fair number of changes on the relay side. So all that's
wrapped in #ifdef RELAY_VIA_HTTP (and turned off.)
Was coming in as a string when called via curl. This may be a problem
for other ints if I go with lots of params instead of a json, which is
looking less likely.
join's how devices will create or join existing games. It more
compilicated than I'd like but seems to work except that once a slot's
assigned it's unavailable to anybody else even if the other fails ever
to respond (i.e. needs the ACK function of the c++ relay.)
If I want to move relaycon into common so Android can use it (assuming
the jni code starts including json-c and libcurl so it can handle
networking) I'll need a replacement for GSList. This is a start.
With the new http stuff, at least for now, it takes longer to get things
communicated and so killing games after 2 seconds of runtime meant no
moves ever got made. Making it configurable, and passing 10 (seconds)
means nearly all games in a large test run complete reasonably quickly.
ACK doesn't need to wait 2 seconds for a reply, and when it does so the
next send waits too. Eventually we'll want to combine messages already
in the queue into a single send. For now, this makes things better.
Change how acks are handled by adding ability to look up connname by
combination of hid and token. It's a bit of a hack, but it's already
there in the protocol and enough to find the game.
