2.3 KiB

Raw Blame History

RPC

This section is a work in progress.

The RPC subsystem is exclusicely in Server Agents. It is comprised of two main components:

the "RPC Server" (for lack of a better term) handles multiplexing of many different requests on a single TCP port.
RPC endpoints handle RPC requests and return responses.

The RPC subsystems handles requests from:

Client Agents in the local DC
(if the server is a leader) other Server Agents in the local DC
Server Agents in other Datacenters
in-process requests from other components running in the same process (ex: the HTTP API or DNS interface).

Routing

The "RPC Server" accepts requests to the server port and routes the requests based on configuration of the Server and the the first byte in the request. The diagram below shows all the possible routing flows.

^source

The main entrypoint to RPC routing is handleConn in agent/consul/rpc.go.

Development

Multiplexing several protocols over a single server port helps to reduce our network requirements, but also makes interacting with Consul using local development tools such as grpcurl difficult.

You can get a "plain" TCP connection to the gRPC server using this proxy script:

$ go run tools/private-grpc-proxy/main.go localhost:8300
Proxying connections to Consul's private gRPC server
Use this address: 127.0.0.1:64077

Pass the returned proxy address to your tool of choice.

RPC Endpoints

This section is a work in progress, it will eventually cover topics like:

net/rpc - (in the stdlib)
new grpc endpoints
Streaming
agent/structs - contains definitions of all the internal RPC protocol request and response structures.

RPC connections and load balancing