To avoid inviteless relay games not having an mqtt channel (and so
yielding a crappy experience) pass the mqtt devid when device registers
and when server replies with all-here.
This is meant to replace the relay eventually, but for now it's a new
option, like BT or SMS, to be chosen. Protocol is handled in common/
code for the first time, meaning that linux and android interact without
the need to keep two platforms in sync. Linux uses lib-mosquitto, and
Android uses eclipse's Paho client (the generic java version, not the
one that uses four-year-old Service patterns and so crashes for SDK >=
26.)
I was getting an occasional crash using a stale env to delete a dict's
resources because the dict was cacheing the env that created it. Dumb!
Using the thread->env mapping stuff worked, but that felt risky and so I
tried just passing it in. It's safe, and involves an amount of change I
can tolerate. So likely going that way.
With these changes the test script no longer produces games that don't
finish. I think they are recovering from the problems produced by one
device doing an undo while another is making a move, or other problems
produced by undo being allowed to happen on any device at any time, but
haven't analyzed the games beyond the test script's verifying that they
all finish with a Winner after all tiles are consumed.
There are still some stalls turning up when running the test script,
especially with more than two players in a game, but but it'll be
easier to do the final debugging off my pathetic travel-only
chromebook. And things are already much better. :-)
Lots of changes adding a games-list view to the app from which you
create new games, open and delete existing ones, etc. There's still
plenty that's unimplemented, but it's already more useful for testing
and development. Which is the point.
Use low-level NFC, a combination of emulated card and reader mode, to
work around Google's removal of "beaming" support from Android 10. App
emulates a card by declaring support in its AndroidManifest. When a game
is open that has data to send, it goes periodically into read mode. If
two devices are touched while one is in read mode and the other isn't,
they handshake and open a connection that should last until they're
separated. The devices loop, sending messages back and forth with or
without data (as available.)
I think I'm seeing a bug where msg <n> is received, I record that I'm
now looking for msg <n+1>, fail to process <n> (perhaps because some
resource is temporarily unavailable?), and am now in a state where I
won't accept <n> when it's resent. This fixes this by only recording <n>
received after processing code has accepted it.
Darned thing was dropping packets, failing to connect games built in
response to invitations, and otherwise misbehaving. First was due to not
resheduling when exited with outbound packets in queue; second to not
overriding relayNoConnProc() (due to signature change.) Though it still
happens occasionally.... Also added timestamps to track how long it
takes a packet to be sent and ACK'd.
My VSIZE is no longer legal, and apparently there's no workaround (no
way to safely figure the length of an array whose size is known at
compile time.) To avoid the risk of duplicating little constants, added
macros that define length in a way a new VSIZE can pick it up. Couldn't
make that work for struct field arrays, however, so there I'm using
constants.
I'm seeing a rare case where a game connectes to relay specifying a room
and somehow gets both slots, having provided different gameSeeds the two
times. This means an opponent won't connect, the room being full in that
game. I can't reproduce, so am logging seed changes better and switching
linux client to leave seed generation to comms as Android does.
It's done for other comm types too, and is necessary to get linux test
script to pass once I make SMS delivery unreliable. But it may duplicate
the tickle that Android's doing and result in duplicate messages: test.
Trying to separate what's game-specific from what can be app/device
specific (i.e. with a long lifespan, and available when a game isn't
open.)
Android will be broken after this commit and fixed after the next
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.)
I'm seeing assertions when a game gets into a state I don't fully
understand: host receives messages that need a channelNo assigned but
the game's full. With luck they're duplicates and can be ignored,
because that's all I can do.
An edge case, but: doing "new from" on a game without any connection
types crashed because of an assertion in comms that assumed
addr_setType() was being called on zero-initialized flags, which
shouldn't have been a requirement. Pulled that as well as java code that
added RELAY-type connectivity to any game that had none. If a game has
none, leave it that way.
Grab and store the local device's mac address. Add p2p as a type of
address, represented by the mac address of the recipient. Include the
local device's address in invitations sent when specified by user. Now
the WifiDirectService class is being passed a packet and the address of
the recipient; it will next need to set up sockets with every device it
encounters and map them to their mac addresses so that it can do a send.
count them, and do so based on new msgNo passed from comms that's
concatenation of channelNo and msgID so that duplicates (over multiple
transports) aren't counted twice.
