When grouping to allow multiple packets per outbound API call I forgot
that some are there to mark the end-of-queue: can't be sent! Trying
caused a NPE. Now if any EOQ is found in the queue that batch is dropped
and the thread's exited.
AddrInfo now has ref()/unref() and keeps a global socket->refcount map
(since actual AddrInfo instances come and go.) When the
count drops to 0, the existing CloseSocket() method is called. This
seems to fix a bunch of race conditions that had a socket being closed
and reused while old code was still expecting to write to the device
attached to the socket the first time (along with lots of calls to close()
already-closed sockets, attempts to write() to closed sockets, etc.)
Use of mutex logging recurses infinitely if config uses mlock, so remove
that. And don't free sockets after handling their messages as they may
be in use elsewhere. This likely introduces a leak of sockets.
Haven't seen it happen, but I think there was a bug that could have led
to all the sockets coming back as ready from poll() being dropped. Fixed
that and added/cleaned up some logging.
translate the most-used features of my too-big-for-bash script into python3,
which is clearly much better suited. Tried to keep the structure and variable
names intact so that diff has a chance of showing something, but when a class
replaces a bunch of arrays that were being kept in sync there's only so much
you can to. Currently doesn't support stuff like app upgrades and switching
from tcp to udp, but those should be relatively easy to bring over from the
.sh when/if I need them.
translate the most-used features of my too-big-for-bash script into python3,
which is clearly much better suited. Tried to keep the structure and variable
names intact so that diff has a chance of showing something, but when a class
replaces a bunch of arrays that were being kept in sync there's only so much
you can to. Currently doesn't support stuff like app upgrades and switching
from tcp to udp, but those should be relatively easy to bring over from the
.sh when/if I need them.
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.
using g_add_idle() for each piece of data received on the (background)
curl-query thread wasn't working. They were getting starved, and I think
some were considered duplicates and never scheduled. So add a single
timer proc called every 50 ms and a queue that it checks and into which
the network thread can put stuff.
Somehow I've been failing to treat this column as an array for some
time. I don't have any test cases that failed but it was clearly
wrong. Test cases still pass....
It's a runtime-only thing, explicitly removed from db on boot. So add a
map from connname->cid to the dbmgr class and modify that rather than a
column. Passes discon_ok2.sh tests as long as use-http stuff isn't on.
