Transports

Transport is a deployment choice, not a design constraint.

A transport is the connection between two adjacent zones. The same generated interface runs over an in-process call, a shared-memory queue, TCP, TLS, a WebSocket, or an SGX enclave boundary — choosing which is a matter of how you construct the connection, not how you write the service.

Available transports

Local In-process calls between parent and child zones, carried by direct i_marshaller calls rather than a stream. Calls within a single zone need no serialisation at all.

Dynamic library RPC across a plugin or shared-library boundary, so a loaded module is addressable as its own zone. Blocking or coroutine.

SPSC queue A lock-free single-producer/single-consumer shared-memory queue — the lowest-latency path for same-machine work. Coroutine build.

IPC Inter-process communication to child processes and their libraries, carried over SPSC queues. Coroutine build.

TCP Host-to-host RPC over a byte stream. Runs on the coroutine scheduler or the blocking executor.

TLS Encrypted network transport. The OpenSSL path is dual-mode (blocking and coroutine); the mbedtls path is coroutine-only.

WebSocket The same interface reachable from a browser through a generated JavaScript client. Requires a configured executor.

SGX enclave RPC across the boundary into an Intel SGX enclave for confidential computation, with optional DCAP evidence and protected-route policy layered above the transport.

LoRa (future) Long-range, low-power links for remote sensing, field infrastructure, and intermittently connected sites, with framing, addressing, and delivery policy selected for the deployment.

Transports are pluggable: a custom transport implements the same interface, so a link Canopy does not ship can be added without touching service code.

Remote attestation is a route-security capability, not a property silently implied by crossing an enclave boundary.

Adjacency, and routing past it

A transport only ever joins two adjacent zones. When the zones a call needs to reach are not directly connected, Canopy routes through the zones in between using passthroughs — automatic multi-hop forwarding that keeps the whole path alive while traffic flows along it. A zone can exist purely to route, with no objects of its own.

This is what lets the topology be whatever the deployment needs: a flat peer mesh where zones connect as equals, or a hierarchical tree with a root zone and child zones for plugins, subprocesses, and enclaves. Either way, an object at any depth in any zone can call an object at any depth in any other — the caller never has to know how many hops, or which transports, lie between them. See Architecture for the zone and service model.