Below the list the supported authentication methods:
anonymous: Allows access to clients which connect without credentials, assigning them as members of the 'anonymous' group. You can configure the allowed sources for the anonymous user and the permissions assigned to the anonymous group - but you cannot make the anonymous group a member of another group.
password: Allows access to clients which connect with an existing username (WAMP authid field) and password, where the password is send in clear-text and is therefore vulnerable to password “sniffing” attacks, unless the connection is protected by TLS encryption. It should be avoided and replaced by the use of wamp-cra or wamp-scram challenge-response methods if possible.
trust: Allows access to clients which connect with an existing username (WAMP authid field) but does not request them to authenticate. This is to be used in conjunction with source definition e.g. trust only clients within a defined network (CIDR).
ticket: Allows access to clients which connect with an existing username (WAMP authid field) and a ticket previously generated by Bondy. If the transport is not encrypted, this method is vulnerable to ticket “sniffing” attacks, a man-in-the-middle can sniff and possibly hijack the ticket. If the ticket value is reused, that might enable replay attacks. It should be used only when the connection is protected by TLS encryption.
Active Anti-entropy (AAE)
AAE is a periodic automatic synchronisation protocol used by Bondy to remove inconsistencies between data replicas (aka Entropy). Bondy uses it to proactively identify and repair inconsistent or missing data across all nodes in the cluster.
Bondy uses a Push-Pull Anti-entropy strategy.
When performed, cluster nodes tell each other about the keys and what versions they have (using Merkle Trees. If they notice a divergence then they start sending each other the differing keys. If a key has conflicting values Bondy will run a conflict resolution function (different entities in Bondy use different conflict resolution functions).
Distributed applications are applications or software that run on network-connect devices and communicate with each other using one or more communication patterns.
In a distributed system like Bondy, conflicts between object replicas stored on different cluster nores are an expected by product of node failure, concurrent client updates, physical data loss and corruption, and other events that distributed systems are built to handle.
These conflicts occur when objects are either:
- missing, as when one node holds a replica of the object and another node does not, or
- divergent, as when the values of an existing object differ across nodes.
A Merkle Tree is a hash tree where leaves are hashes of the values of individual keys. Parent nodes are hashes of their respective children.
This feature helps to recover data loss in the event of disk corruption.
In a mesh topology there is no central connection point. Instead, each node is connected to at least one other node and usually to more than one. Each node is capable of sending messages to and receiving messages from other nodes. The nodes act as relays, passing on a message towards its final destination.
There are two types of mesh topology:
- full mesh topology
- partial mesh topology
An architectural style where applications are constructed from services that communicate over the network using RPC and are developed, scaled and deployed independently.
The key goal of a microservices architecture is to modularize application development into independent yet collaborating components, each delivered by smaller team of developers that don't need to understand the entire application and allowing each team to work at their own cadence.
Unless otherwise specified in the documentation, the word "process" refers to an Erlang process, a lighweight concurrency primitive with small memory footprint that operates independently and is scheduled by the Erlang VM.
A Bondy node can manage millions of concurrently executing processes.
Remote Procedure Call
A service mesh is a dedicated network layer that sits above the service layer and enables service-to-service communication. Its communication channels rely on distributed APIs instead of centralized and discrete appliances.
Messages are transported within the service mesh, but the messaging functions are performed alongside the services receiving the messages. Each instance is attached to a proxy that relays messages to and from the service mesh. These proxies then perform many functions traditionally performed by middleware such as message routing and blocking, service discovery, load balancing, encryption, authentication, and authorization. They additionally support features such as discovery, routing, reliability (failure handling, circuit-breaking), observability and request tracing.
Christopher Meiklejohn, Strangeloop 2022 Resilient Microservices without the Chaos ↩︎