(Back to ChatApp project , Final Project)
The following is a diagram illustrating the various communications pathways between clients, between clients and a server and between commands on the same client.
(View full-size image)
Important take-aways:
- Communications between different clients as well as between clients and servers is by message-passing.
- Communications between commands on the same client, is via adapters.
- Commands obtain adapters by retrieving them from the local data storage.
- The adapters connect the commands to any sorts of shared views and/or processing entities.
- The "game model" shown is technically just a processing module for centralized operations on the client. Not all systems need this.
- Adapters are typically placed in the local storage by a command that is tasked with configuring the game's "micro-MVC" on the client, e.g. a "make game" type message processing command.
- While the above diagram shows a "game model" entity, technically, when everything is connected by adapters, the micro-MVC consists of all the created views, centralized processing modules (e.g. the "game model" shown) and the individual game commands.
- Remember that an MVC is not relegated to a single "model" and a single "view"!
- The local storage can hold any type of data, not just adapters.
- Always program defensively: Do not assume that the adapter will be in the local storage at the time that a command attempt to retrieve it. Be prepared to deal with the possibility of a race condition with regards to one command putting in the adapter and one command retrieving it.
- There are many ways to deal with this issue, of which careful message sequencing is often the most effective.
For more information on using local data storage including implementing them with Mixed Data Dictionaries, see Mixed Data Dictionaries and Inter-Module Communications.
Note: The above diagram does NOT address either team/room formations or room roster synchronization.
© 2020 by Stephen Wong