Interaction Model
The interaction model in GoCollaborate provides distributed application hosting, service management, cluster communication, server expansion and fault-tolerance capabilities based on many of the classic distributed solutions. To give a better idea around how GoCollaborate works with these features, we will briefly explain the functionalities each module support, and how they collectively forms the architecture of GoCollaborate.
Collaborator
A Collaborator is a single computational node that holds one Master and tens of Workers. Collaborators can discover and connect to each others by sharing their Card. All of the known Cards shared across the GoCollaborator network together identify the addresses of the existing nodes and gradually broadcast the information until the entire network reaches eventual consistency. A Collaborator usually contains:
- Master daemon: manages task execution and recycling
- Worker daemon: listens to task channels and executes task where available
- Publisher daemon: accepts Job from both exposed APIs and peer nodes, break down the Job into multiple Tasks according to their dependencies (please refer to the concept of Stage in section Executor) and publishes them to local Master
- Store daemon: provides a shared memory space for all routines running on the same node
Coordinator
A Coordinator is a service management center where the new joining clients from various endpoints can dynamically check out the latest provision of services running on GoCollaborate network. Each Collaborator will register their identity along with the services it hosts at one centralised Coordiantor. The status of these services will be updated and broadcast to all subscribers whenever a different version is synchronized.
Case
A Case is a virtual card case the Collaborator uses to manages the cards it holds. The Case in GoCollaborate acts as a distributed identity management module for Collaborators within the same cluster. Messages received on each Collaborator should always be verified before going into effect. Random messages from unidentifiable sources will be blocked out from the Case network. This mechanism effectively prevents the spreading of malformed messages while enchancing the robustness of the cluster.
Card
A Card is a local stub of one particular peer Collaborator working in the same Case as it does. Collaborators start calling each other by referring to the Cards held in their own Case. Each card is comprised of the ip address, the port number as well as the aliveness of its referencing node that, consistently, sustains the routing of Tasks passing through the cluster network.
Gossip Protocol
Unlike some other consensus algorithms, GoCollaborate is built on top of the Gossip protocol where there is no quorum of nodes required to reach a concensus of data truthness. One common issue existing in most of the popular consensus algothithms is that the entire cluster network will become unavailable when over half of the nodes have been unexpectedly polluted.
Why Gossip?
In comparison to other CAP theorem implementations, GoCollaborate values availability and partition-tolerance over the strong consistency.
The idea also aligns with the design principle of GoCollaborate where services running on each single node should be organized in a stateless manner.
Dynamic Membership
GoCollaborate implements dynamic membership in the Case network. A check-in routine will be pulling the latest information from its neighbouring nodes until all of them eventually get synchronized. Nodes within the network can join or leave the cluster network at any time, where their existence will be updated after a Catch-Up Interval (default to 3 mins) or up until another Collaborator catches up with it.
Networking
Network Address Translation
GoCollaborate will automatically translate the local address of your hosting machine to the exposed address that is all ready to be shared across other servers. No extra configuration is required to modify your case.json file thereof.