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.
postEmptyEvent; pass transport type with incoming packets so they can
be rejected if not on expected channel (to stop IR, which is always
on, from injecting into a BT game); do BT work and fire timers even
when menu is down; don't let robot run until after board is drawn for
the first time; on startup, don't let robot run until after board is
drawn once. Up version to b3.
while heartbeat feature was enabled. Fixed the problem on Linux, but experience on Treo650
is still better without HB feature, so turning it off on Palm. This seems ready for beta,
but will test a bit more.
and use it to send and check for heartbeats over any transport.
Caller must supply a reset proc which is called when heartbeat hasn't
been received in too long. No changes required to comms protocol, but
that means the heartbeat interval is fixed at compile time: can't be
negotiated, and the two ends had better agree. Currently tested with
linux host and PalmOS guest, where only the first heartbeat failure is
recovered from. So there's some debugging to be done still.
that a new game's begun without dropping the connection. On Palm,
remove connection-drop on new game. With this change starting a new
game takes imperciptible time, down from 30 seconds.
running the old game: the host may reply, but guest must not take that
as evidence of a connection having been established: don't remove sent
messages (this isn't an ACK), and don't assert later on.
A full robot vs. robot game now works between two Treos. Added UI to
choose BT as transport mechanism, and added new send proc to establish
socket connection between host and guest. Works only for two devices:
no piconet yet. No error recovery, ability to quit game in middle,
start new game, etc.
deal with the output by removing params where possible and elsewhere
by adding XP_UNUSED macro wrapping __attribute__((unused)). There
should be NO change in function in spite of the large number of files.
send player counts, local and expected. Based on these the relay
accepts connections, declares the game full and ready for message
forwarding, and decides whether to accept a reconnect.
scheme where cookie is used only to connect, and is replaced for
reconnects by a relay-generated name that's supposed to be unique
across all games on all relays; let relay assign non-servers' hostIDs
rather than doing 'em randomly; use hostIDs for comms-level protocol's
channelNo where possible to avoid tripping over duplicate messages
Include cookie users will agree on on for relay rendevouz, and
sender/receiver IDs for when there are >2 devices in game. Supports
games between linux clients now, but needs a lot more work.
