This document provides a high-level overview of the gRPC Core architecture. gRPC Core is a library written in C++ that provides a portable and performant implementation of the gRPC protocol.
The gRPC Core is built around a few key concepts:
- Channels and Calls: A channel represents a connection to a gRPC service, while a call represents a single RPC. The
calldirectory contains the fundamental data structures for managing a call's lifecycle. - Transports: A transport is responsible for sending and receiving data over the network. gRPC Core supports several transports, including CHTTP2, in-process, and an experimental "Chaotic Good" transport. See the
transportandext/transportdirectories for more information. - Filters: Filters are a mechanism for intercepting and modifying RPCs. They are used to implement a wide variety of features, including authentication, compression, and retry. See the
filterandext/filtersdirectories for more information. - Promises: Promises are a framework for asynchronous programming. They are used extensively throughout the gRPC Core to implement non-blocking I/O and other asynchronous operations. See the
lib/promisedirectory for more information. - Event Engine: The Event Engine is an abstraction layer that provides a consistent interface to the underlying operating system's I/O and threading primitives. See the
lib/event_enginedirectory for more information.
- No Exceptions: gRPC Core code does not use C++ exceptions. Functions should return an error code to indicate failure. Possible error types:
- bool - if the error is success or failure for a simple function, this is simple and efficient
- absl::Status, absl::StatusOr - a good fallback for cross layer code
- StatusFlag (in src/core/lib/promise) - a boolean that is recognizable as an error condition by the promise library; the same library provides ValueOrError that fills the role of StatusOr for this type
- It's ok and recommended to write a bespoke error type if your failures don't fit the above mold. It's strongly recommended to provide a mechanism to reduce custom errors to absl::Status for portability between layers.
The gRPC Core is organized into the following directories:
call: The heart of the gRPC C++ core, defining the fundamental data structures for an RPC.channelz: A system for inspecting the state of gRPC channels.client_channel: The core implementation of the client-side channel, including name resolution, load balancing, and connectivity.config: Manages static and dynamic configuration of the gRPC Core.credentials: The core implementation of gRPC's credential system.ext: Contains extensions to the gRPC Core, including filters and transports.filter: The fundamental building blocks for the gRPC channel filter mechanism.handshaker: A framework for establishing a secure connection between a client and a server.lib: A collection of libraries that provide common functionality, such as data structures, memory management, and platform-specific code.load_balancing: A flexible and extensible framework for load balancing.plugin_registry: The main entry point for configuring the gRPC Core library.resolver: A pluggable mechanism for resolving a logical name into a list of network addresses.server: The core implementation of the gRPC server.service_config: A mechanism for per-service and per-method configuration of a gRPC channel.telemetry: A system for collecting and reporting metrics about the behavior of gRPC.transport: The core transport abstraction for gRPC.tsi: An abstraction for different transport security mechanisms like TLS and ALTS.util: A collection of utility classes and functions.xds: An implementation of the xDS APIs, which allow a gRPC client or server to discover and configure itself dynamically.