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.
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.)
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.
the case where one of several guests wants to rematch is a hard
problem for later.) Requires passing old-style relayIDs (connname plus
device index) when devIDs aren't available, which they may not always
be.
for Rematch): works for linux version, provided you know the relayID
of the device you're inviting. Added to common/ a stream-saving
version of java's NetLaunchInfo I'll probably want to use there too
for cross-platform compatibility (there being no jni support for
json.)
needs to save it there on receipt of an invitation (doesn't create
full game with comms until later.) Passes discon2 tests and seems to
work on a single Android device. (Haven't tested inviting on Android
yet.)
Works for large numbers of relay games in test, but will not yet
actually hold more than one value. Should be safe to merge to main
branch once stream upgrade is verified.
message over and over when getting updated by GCM. The problem
occurred when one device had an un-ACKable initial message still in
its queue. I call resendAll a lot, which caused that message to get
resent to the other game which then replied without being able to ACK
it so it remained to be sent again. This would continue until users
moved forward in the game. The fix is to add a backoff timer to
resendAll() so that it can't loop. The timer is reset when an ackable
and new message is received, meaning there's been a change in what's
available to resend. And since users calling resendAll manually
expect it to do something, add a force param that ignores the backoff.
seems to fix the problem (but needs a lot of testing.)
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.
save what it had ACK'd leaving the game permanently broken. Do that
by adding a new method game_saveSucceeded() called after the client
claims to have committed bytes returned by game_writeToStream() to
disk. In that method comms updates the value it'll use in subseqent
ACKs.
remote device[s] as part of summary view and in game config screen
(read-only). Use same field in summaries table for remote phone
numbers and bt addresses.
devices in summary DB so, e.g., we can quickly determine what games
care when a devices becomes available via BT. First use of this is
notifying when a remote game's deleted -- least that's the plan. This
commit just adds to the DB and scans the DB to build a map of
device->gameIDs array.
that implies a connection) is sent and received by no-conn code. Use
flags to determine if comms can support no-conn sending without making
up the message only to have it fail to send.
without user having to open the game, which will e.g. allow a host to
assign tiles, or a robot to move, without the phone's owner noticing
there's a message. This is on a branch because it may never work.
