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
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.
of which is TBD). When a new-version client connects, store the value
it's passed. At first this will let me track how quickly people
upgrade. Later I can use it to let different clients have different
formats to their messages e.g. to proxy.
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.
into the java world by making it a util_ctxt function. Do same on
linux to test. We'll see how it is -- and can back this commit out if
there's no improvement.
to send a message from a client immediately after its initial message
but init-message dupe-detection in comms will drop that because only
one channel-0 message is expected -- the initial connection message.
So don't encourage platform code to enable the feature before common
code can deliver the message.
RECONN or CONN that lists the game as full. This means we get the
all-green icon (or the A in the gtk case) when in a consummated game
rather than only when all devices are actually connected.
message to be sent next time it does. And since the cookieID will
change and should be there already anyway, remove it. (Should remove
the hostID too for the same reason.)
game works to completion with both signing up as guests (no -s) with
one local and one remote player (identical commandlines.) Not yet
tested: if any signs up as a host, reconnecting rather than
connecting, etc. This is just a snapshot.
device id, to relay, one for each stored game that's communicating via
the relay. Relay parses out each relayID. Next relay can use these
to look up whether messages are available and reply with that, and
device can put up a notification.
duplicate initial packets a bit better. This change goes with the
next checkin on the relay side: move to modified store-and-forward so
devices can connect at different times once the game is established.
name. All new connections are stored together, and after each
connection an attempt is made to build one complete game with a host
and however many guests. All remaining devices are moved into a new
pending record in the same state, and the completed game is treated as
always. Seems to work, though nearly 20% of linux instances are
failing to connect the relay run from the new test script samename.sh.
Need to figure out why.
Also added logging of seed and connname to comms.c since games
launched together can no longer be certain to connect on the relay.
This allows the test script to identify joined games from their logs
and detect success or failure.
This checkin changes the relay protocol, so relay and clients will
both need to be upgraded.
setting connName when all in a game are present. Second, have every
host include in connections a random number. That number is made part
of the connName and in general used to test whether a host belongs in
a particular game. Add this "seed" to web interface. Means new
versions for relay protocol and game stream format. Latter is handled
correctly so older games can be opened.
cookie winds up connecting to the old game -- by flagging a cref as
full and no longer accepting connections without connNames even when
in the MISSING state. Required a protocol changes so that devices get
their connNames as early as possible.
ALLHERE message and connName: change relay protocol so cookie is
included in RECONNECT message, and hostIDs are not assigned until
ALLHERE, and change host-to-game matching to use connName first but
fall back to cookie. This fixes nearly all cases failing to reconnect
after relay goes down.
base64-encoded data as the messages. Make necessary changes to comms.
This is the foundation for doing real SMS transport on handhelds.
Currently a full robot game works for two gtk clients provided the
server is launched first.
