Two cases dealt with here. First, if my opponent deletes the game when
I have an un-ack'd message, I'll keep sending it forever. Fix is to
flip a bit in comms in response to a game_gone event so no more
sending will happen. (Better than emptying the queue, as it leaves
open the possibility of resurrecting the game with code changes
later.) Second, if there's a retained message from a dead game I'll
keep receiving it until it's replaced, and if the game's dead it never
will be. Fix is to add a new api endpoint noSuchGame() to the relay2
server and to call it on receiving a message for which I have no game
to deliver it to. The endpoint "unretains" the message so I won't get
it again unless it's resent.
My combining messages logic failed for ACKs, sending the queue but not
the ACK unless the ACK was in the queue. Appending it at send time is
fraught, so I am instead adding ACKs to the queue, but not persisting
them, so they only last long enough to be sent after they're
added. Seems to fix a common problem of games failing to get ACKs for
their final messages after they finish.
Was dropping invitations that were posted before I connected to the
remote broker. Now they're kept, and sent until the broker says
publish succeeded. Better would be to have comms resend when mqtt
connects, but I'm not set up for that.
Server needs to not rematch if any device has more than one
player (for now, as I'm too lazy to fix this rare condition.) I'm
moving toward having the linux client write status to a unix socket on
exit rather than having the test script parse the log file for
status. GameOver is there now. Tile counts should follow.
Because only the host/inviter knows the addresses of all the devices
in a game it's hard for guests to rematch (unless it's a 2-device
game, as they know the host's address.) So now, as part of telling
guests the game is ready to play, include the addresses of other
guests. It's usually only 9 bytes per device, and only happens when
more than two devices are in a game.
No point in sending the old-topic-format MQTT messages to clients that
know about the new one, and in fact it's harmful. Devices in a game
already agree on the stream version to use and communicate it, so pass
that into comms once it's known and from there on to the device code
that builds mqtt messages.
