Cluster Communications heading-link-icon

Communication between workers, within a cluster, is mostly achieved through the internal message bus, integrated with Kafka The means by which Corda workers communicate, acting as a central message bus between the worker processes. . However, communication originating from outside a cluster usually uses the HTTP protocol.

Interaction with the Corda cluster for administration or flow Communication between participants in an application network is peer-to-peer using flows. management uses a REST API over standard secure HTTP (HTTPS). These HTTP REST endpoints are exposed by the REST workers A worker that exposes the intranet HTTPS REST control ports of the Corda cluster. The REST workers support all of the dynamic administration APIs of the cluster, such as APIs to configure the cluster, set up user role based permissions, or create and register virtual nodes. in the cluster. Like other worker JVM processes that run in a cluster and perform a specific task. The processes required to form a cluster depend on the deployment topology. Workers increase or scale back their capacity depending on the number of available tasks. types, REST workers are stateless, so requests can be divided across all REST workers using a standard HTTP load balancer, which must be exposed to the application and/or user that interacts with the cluster.

HTTP requests are authenticated using basic authentication, and authorization is based on Corda’s RBAC capabilities.

Communication between different Corda clusters to support distributed workflows, that is peer-to-peer (P2P) communication, also uses standard secure HTTP (HTTPS). The components of the peer-to-peer communications layer are responsible for delivering messages between virtual nodes in a secure and reliable way. If the two virtual nodes communicating reside in the same cluster, the messages can be routed back without exiting the cluster at all. If the two virtual nodes communicating reside in separate clusters, the P2P link manager Establishes end-to-end secure sessions for virtual nodes to communicate over. processor is responsible for establishing end-to-end authenticated sessions with the link managers on the other cluster in order to transfer the messages in a secure way. The link manager is also responsible for ensuring the message is delivered reliably in the case of any transient issues in the network path between the two clusters. Any messages destined for a separate cluster are forwarded by the link manager to the P2P gateway, which forwards them to the P2P gateway of the other cluster via HTTPS. A gateway can connect to another gateway in a separate cluster via mutual TLS Transport Layer Security. A protocol that establishes an encrypted session between two computers on the Internet. , depending on the policy of the application network.

Was this page helpful?

Thanks for your feedback!

Chat with us

Chat with us on our #docs channel on slack. You can also join a lot of other slack channels there and have access to 1-on-1 communication with members of the R3 team and the online community.

Propose documentation improvements directly

Help us to improve the docs by contributing directly. It's simple - just fork this repository and raise a PR of your own - R3's Technical Writers will review it and apply the relevant suggestions.

We're sorry this page wasn't helpful. Let us know how we can make it better!

Chat with us

Chat with us on our #docs channel on slack. You can also join a lot of other slack channels there and have access to 1-on-1 communication with members of the R3 team and the online community.

Create an issue

Create a new GitHub issue in this repository - submit technical feedback, draw attention to a potential documentation bug, or share ideas for improvement and general feedback.

Propose documentation improvements directly

Help us to improve the docs by contributing directly. It's simple - just fork this repository and raise a PR of your own - R3's Technical Writers will review it and apply the relevant suggestions.