Introduction

The gRPC NDK allows you to add your own configuration to the system in a non-persistent manner. An NDK-added configuration is considered short-term, and its state is bound to the state of the agent. If an agent fails, the configuration added by the agent using the NDK is removed.

Agents can also add configurations through normal APIs (gNMI/JSON-RPC/CLI). This configuration persists across an agent failure, and the only way to remove it is to overwrite it with a commit command. The short-term datastore is used for agent route injection, while traditional methods for configuring the device are persistent.

SR Linux uses gRPC for inter-process communication. gRPC is a client application that directly calls methods on a server application on a different machine as if it was a local object. The supported external APIs (CLI, gNMI, and JSON-RPC) communicate with the SR Linux and retrieve state information using gRPC.

On the server side, the server implements the interface and runs a gRPC server to handle client calls. On the client side, the client has a stub (or client) that provides the same methods as the server.

gRPC clients and servers can run and talk to each other in a number of environments and can be written in any supported gRPC language. Clients can be created in Go, Python, Ruby, or any other language with gRPC support.

SR Linux’s gRPC NDK uses protocol buffers. Protocol buffers are automated mechanisms for serializing structured data. You define how you want your data to be structured once, then you can use special generated source code to easily write and read your structured data to and from a variety of data streams using a variety of languages. You can also update a data structure without breaking deployed programs that are compiled against an old format.

When working with protocol buffers, structure is defined for serialized data in a proto file (a regular text file with a .proto extension). Each protocol buffer message is a small logical record of information containing a series of name-value pairs. Each message type has one or more uniquely numbered fields, and each field has a name and value type.

Messages also have optional arguments that specify if fields are optional, required, or repeated. New fields can be added to message formats without breaking backwards compatibility, and old binaries ignore any new fields when parsing the message. This allows the gRPC NDK to evolve over time without impacting current deployments.

Once the data structure is specified, a protocol buffer compiler (protoc) generates data access classes from the proto definition. These provide simple accessors for each field (like ConfigData() and set_ConfigData()) and methods to serialize and parse the complete structure to and from raw bytes.