- To provide a low maintenance platform for the SOMAS coursework
- To ensure developers working on SOMAS logic do not need to bother much on infra, effectively segregating the responsibility between infra/non-infra
- To ensure high availability and reliability of the platform
- To maintain a platform that acts in everyone's interests to reach all SOMAS goals
- See here for discussion on that and a MWE for C++ server and C++ & Python clients
- MWEs: Golang, Python+mypy
- C# (.NET) MWE coming soon (CC Yusuf)
- Personally I tend towards Golang... but let's discuss with your teams.
- Multi-language single process: possible (see stuff like IronPython or Edge.js), but these are niche stuff
- Single-language multi-process: why if concurrency is free in some languages?
There will be one central server tracking the state of the game. The server would send "requests" to clients to get a response (hence client-server technically a misnomer).
Clients responses can be blocking or non-blocking (ideally), ideally concurrently (Golang :)).
Clients would be responsible for tracking their own state and handling requests sent by the server.
Please refer to the CW prompt document for more information.
- Server will tell everyone the day has started
- In the same request, the response will include whether a rule modification is proposed
- If this is proposed, then we will engage in a voting mechanism to change the status of rules
- Server will tell everyone the state of islands (resource levels, whether people need anything)
- Messaging mechanism for gifts or discussion
- Server will request for amount of endowment each island will offer for the pool
-
Core infrastructure, CI,state management
-
Rule mechanism
-
Voting mechanism
-
Gift, Discussion and agreement (messaging)
Each person will be a champion for a mechanism we have. This ensures that we have a clear point of contact for issues in an area.
- 2x core infra
- 1x rule
- 1x voting
- 2x messaging and comms
These numbers are subject to change. Being a champion doesn't mean you have to do everything, it is still a team effort but a champion will effectively own that part of infrastructure.
-
Messaging and comms are quite difficult, and a lot have to be considered. For now, imagine that island A needs 20 units of resources to survive. Island B is ready to offer 15 units and Island C 10 units. We want islands to be able to respond to what other people do, but this would be unfair. One solution is to use message queues, but this doesn't solve everything (you may need to process conflicting/unneeded messages (e.g. island B already offers 20 and island C's message in the queue offer 10)). I'm thinking of the simpler approach of shuffling the islands and, if a response is present, broadcast the message. We will allow raw messages for agreements, so that people can "collude".
-
Infra will not cater to requests for "typing custom messages". We will just have generic structures, and will only type things that the server needs to understand. All messages will be broadcast (to all islands) and islands can decide amongst themselves how to do encryption or whatever. During a messaging round we can just keep looping until no one has anything to say (or a limit). Among the islands, they can communicate via raw strings that they agree upon. This is so that infra is not overloaded and we can also participate in SOMAS items.
- Main repo with write and merge permissions to infra team
- Each team will fork the repo for their own development
- PRs into the main repo will be reviewed and must pass CI
- GitHub actions will run the necessary tests + type checks. It's free for public repos (which ours will be)
- If all tests pass, simulation will be run on GH actions as well, then we will figure out how to publish results (via issues or something).