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.
been set up. Fixes assertion firing when SMS messages go to wrong app
(normal vs CrossDbg), though the right fix is to have the two apps
using different ports so they don't get each other's messages.
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.)
partway through a game. Problem was that once a channel was working
with one means we wouldn't fall back to default addressing for the
means for which we didn't have a return address yet. (NOTE: Not yet
fully tested...)
almost unique 16-bit quantity. 1 in 2^16 new games will fail because
its connID will match, but that's ok in part because it can only
happen during the time between when this is released and follow-on
version that assumes all older versions are gone.
what's going on when multiple participants in a single game are on the
same device. But for a couple of strings passed into the jni the
changes are only in DEBUG code.
server or guest so that sender can tell when it receives a message
from itself (and reject it.) This fixes a lot of confusion in testing
where both participants in a networked game are on the same device,
but might also work around e.g. relay bugs.
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.)
An invitation works with relay and (fake) SMS on, and the invited
client connects successfully using both (the second to arrive being
correctly identified as a dupe.) While the game can be played after,
only SMS messages are being received. And opening a saved game
crashes.
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.
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.)
don't have a connID yet, as this confuses the server. This fixes
assertions in testing that were pretty common when chat was enabled;
it may also fix the reported problem on Android that games get hosed
when people are using chat, as the server's response (without the
assert) was to add a new channel.
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.)
ID_TYPE_RELAY id that's not in the devices table (as has happened when
a device switches relay URLs during testing, but might also happen if
I have to delete an entry from the devices table.) In that case,
return ID_TYPE_NONE to the client, which will be its clue to delete
its ID_TYPE_RELAY id and submit the platform-specific id again.
Note: android won't compile this revision thanks to util.h change
