joshuaauerbachwatson
commented
3 years ago More Design Thoughts
Achieving multicast semantics
Multi-peer communication is. a great match to the needs of the app. It is essentially a multicast group. Any member of the group can push a new state to the other members of the group. No centralized backend is required. To achieve the same semantics with stateful serverless, we have to overcome some impedence mismatch.
In the following I am not yet dealing with how we authenticate players and join them to games. Let's assume the steady state where there is a game underway with a set of identified players.
The state of the game will be kept in the key-value store. The player whose turn it is can push a new game state. Any player can request and obtain the current game state. That's the easy part.
The problem is for players who are not the next to play to know when the state has changed (we don't have push notifications for this communicator). One simple paradigm is to just fetch the game state every second or two. We could also design a more compact exchange that just asks for the current turn number. That is enough to know that something has changed. I have a feeling, though, that extra round trip in the second design is not worth it, given that the game state can never be all that large with just playing cards, represented symbolically.
As originally conceived, the "AnyCards" game had two communication pathways:
The latter has not been implemented. There appear to be some non-trivial setup issues for testing a Game-center based app and the overwhelming bulk of the documentation is about the popular uses of game center for leaderboards and achievements rather than as a broker for multi-person game playing (it supports the latter, apparently, just that there's a bunch of complexity to wade through and the ability to test is in doubt).
Having recently been employed by Nimbella Corp., and having learned a bunch of stuff about the "serverless" paradigm and about how Nimbella supports "stateful serverless", I am going to attempt to write a third communication pathway.
If this works out I may defer the game center implementation indefinitely and perhaps drop it from the plan entirely.
Some design thoughts
Authentication
The Nimbella stack is based on OpenWhisk which has a particular way of doing authentication. What this comes down to is that one can choose to give each Any Cards user a unique Nimbella identity (so that the token associated with that identity must be presented on each invocation) or let the entire backend run with one particular NImbella identity, making the actions that implement the backend public and web-invocable. I think only the latter really works. If every user has their own identity, they will also have their own
redisinstance, which defeats the stateful sharing aspects that I need. Also, it means that my users have to obtain Nimbella ids, which is not a process over which I have much control.But, if the actions that implement this backend are public, that means they could be invoked by absolutely anyone unless I take further steps to restrict access. I think I need such protection to make sure the new backend is not the target of malicious interference or even accidental interference. So, I will need my own support that allows possessors of the app to register for the game and receive some sort of token (I think any large random number would do) that is stored in their app state. This token is subsequently used in playing the game. It could (maybe should?) be passed in the auth header but that requires the actions to parse headers. I think it's simpler to just make it a field in the request data.
To be continued.