UNDERSTANDING OPENCLOVIS COMMUNICATION INFRASTRUCTURE

Introduction

In the world of tightly coupled distributed systems, intracluster communication is a critical element. OpenClovis provides several communications facilities that are used by the SAFplus Platform framework and that should be used by customer software. These communications services are available on every SAFplus Platform node and allow any component to directly communicate with any other component running on any node and allow components to be identified (addressed) either by location or by an arbitrary name (location transparent addressing). This article provides a concise overview and explores the fundamental elements of this infrastructure, its unique features, and how it facilitates seamless communication across distributed systems.

 

Key Components of the OpenClovis Communication Infrastructure

The SAFplus Platform Communication Infrastructure is built on several key components, each serving a specific purpose in enabling efficient communication.

  1. Event Service:

The Event Service is a publish/subscribe multipoint-to-multipoint communication mechanism that is based on the concept of event channels, where a publisher communicates asynchronously through events with one or more subscribers over an event channel.

  • SAF-compliant implementation: Multiple publishers and multiple subscribers can communicate over the same event channel. Individual publishers and individual subscribers can communicate over multiple event channels. Subscribers are anonymous, which means that they may join and leave an event channel at any time without involving the publisher(s).
  • Event Channels can be local or global: The local channel is limited to a single node while a global channel spans across the nodes in the cluster.
  • Guaranteed Delivery: Events are delivered in strict order with options for guaranteed or “at most once” delivery.
  • Event Filtering: The standard set of event attributes includes an array of event patterns. The values of these patterns are set by the event publisher and are used to organize events into various categories. The event is delivered only to those subscribers which have an appropriate filter.

READ MORE

 

  1. Intelligent Object Communication (IOC):

The IOC is a compatibility layer on top of TIPC that will allow customers to port the SAFplus Platform to other architectures. IOC also abstracts and simplifies some of the legwork required to connect a node into the TIPC network.

  • Reliable and Unreliable mode of communication: The IOC with the help of TIPC allows the applications to create a reliable or an unreliable communication port. Reliable communications are highly recommended because message loss may also occur in the Linux kernel or network switch.
  • Broadcasting of messages: This means that a broadcast message sent from a component will reach all components on all nodes in the cluster.
  • Multicasting of messages: Multicasting is sending of a message to only a group of components that had registered itself with IOC for a specific multicast address.
  • Location Transparent/Logical Address to a Component: Transparent addressing support of IOC makes communication possible for an SAFplus Platform component with another SAFplus Platform component without knowing the second one’s physical address.
  • SAFplus Platform node arrival/departure Notification: This feature of IOC informs an event to all the interested SAFplus Platform components in the whole SAFplus Platform system about when a node in the cluster arrives or leaves.
  • The arrival/departure notification of a component: The IOC with the help of TIPC will come to know about every SAFplus Platform component’s health in a system and it conveys this to all the interested SAFplus Platform components through a query or callback interface. Component arrival and departure are actually measured by when the component creates or removes its connection to TIPC.

READ MORE

 

  1. Name Service:

The Name Service enables objects to be referenced by friendly names rather than complex object references like logical address, resource ID, etc. The name service maintains a mapping between objects and the object reference (logical address) associated with the object. Each object consists of an object name, an object type, and other object attributes.

  • Dynamic Mapping: Maintains a mapping between service names and their attributes, including addresses. Service users can communicate with service providers without knowing their logical address or physical location.
  • Dynamic Querying: Query based on “Service Name”, “Service Attributes”, and “Name Space Context”.
  • Dynamic Creating: Name spaces are dynamically created at run time
  • Context-Based Naming: It allows partitioning of the namespace specifically Local Name Spacers and Global Name Spacers.
  • Registration and Deregistration: During registration, an entry (i.e. mapping between “name” and logical address) for the component is added into the name service database, and during deregistration, the entry is deleted.

READ MORE

 

  1. Remote Method Dispatch (RMD):

The Remote Method Dispatch (RMD) is generically known as RPC (Remote Procedure Calls) and enables function calls to be made to services located on different nodes in a distributed environment.

  • Similar to RPC – Remote Procedure Call
  • Low Latency Communication: Communication takes place over the low latency IOC/TIPC layer.
  • Reliable Communication: Guarantees reliable communication (“at most once” semantics)
  • Flexible Call Types: Support both synchronous and asynchronous flavors.
  • Platform Agnostic: Supports mixed-endian and mixed-architecture systems (32-bit and 64-bit).

 

  1. Interface Definition Language (IDL):

The OpenClovis Interface Definition Language (IDL) is a library used by all EOs to communicate efficiently across nodes. It can communicate across mixed endian machines and mixed mode.

  • Platform Independence: Supports mixed-endian, 32-bit, and 64-bit architectures.
  • Automatic Code Generation: It generates client and server-side code for the XML definition into the specified directory.

External Data Representation Standard (XDR) Support: It stores data into a message. This is called marshaling of data. The reverse process i.e. of retrieving data from the message into the native format is called unmarshalling of data.

 

Conclusion

OpenClovis communication infrastructure provides a powerful toolkit. By leveraging components like Event Service, IOC, Name Service, RMD, and IDL, organizations just focus on developing their applications without worrying about reliability, high availability, and performance when communicating.

Other support, please send email to support@openclovis.org.