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.
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.
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.
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
