Module client 

RpcClient: connect, hello, call, ping, close.

The transport is Thunder’s (thunder::Client): one TCP connection per RpcClient, a background reader that demultiplexes responses by frame id so concurrent in-flight calls don’t block each other, lazy reconnect, and typed errors. What lives here is Vectorizer’s shape on top of it — the vectorizer:// protocol config, the HELLO payload/response types, and the error mapping the typed wrappers in super::commands consume.

Auth is per-connection sticky per wire spec § 4, and Thunder carries credentials in the connection handshake (AUTH) rather than in a command. RpcClient::hello therefore re-dials when its payload carries a token or an API key, so the credentials reach the session that later commands run under; the HELLO command itself still runs, because the server answers it with the capability list and auth flags this client surfaces.

Structs

HelloPayload

HELLO request payload.

HelloResponse

What the server returns for a successful HELLO.

RpcClient

One connection to a Vectorizer RPC server.

Enums

RpcClientError

Errors the RpcClient can return.

Constants

DEFAULT_RPC_PORT

Vectorizer’s slot in the 15500-range binary-transport convention shared with Synap; the default when a vectorizer://host URL omits the port (wire spec § 12).

Functions

protocol_config

How Vectorizer uses the Thunder wire — the client half of the server’s vectorizer_config(): vectorizer scheme, AUTH-command handshake, no HELLO negotiation (the HELLO command is Vectorizer’s own), RESP3-style error prefixes.

Type Aliases

Result

Result type alias.