tractor/docs/api/ipc.rst

IPC and logging

Under every portal, context and stream sits a per-peer ~tractor.Channel: a msgpack-typed messaging link wrapping one OS transport connection. Transports are pluggable per actor via enable_transports=['tcp' | 'uds'] — TCP is the default, UDS (unix domain sockets) gives you port-less, same-host IPC with kernel-provided peer credentials for free — and exactly one transport may currently be enabled per actor.

Addresses are "unwrapped" tuples at the API edges: ('host', port) for TCP, filesystem-path pairs for UDS. For the full layering story — transport protocols, the IPC server, address types and the msg loop — see /explain/architecture.

tractor

Channel

Channel

0.1.0a6

Channel.uid warns; use Channel.aid which carries richer (optional) identity fields beyond the legacy (name, uuid) pair.

Note

You rarely construct a Channel yourself — the runtime hands them out via Portal.chan <tractor.Portal.chan> and Context.chan <tractor.Context.chan>. Treat the send/recv surface as advanced API: normal apps should speak ~tractor.MsgStream instead.

Choosing a transport

../../examples/uds_transport_actor_tree.py

Logging

tractor.log provides the structured, colorized console logging used across the runtime — with actor-name + task-aware record headers and extra log levels below logging.DEBUG ('transport', 'runtime', 'cancel', 'devx') for spelunking the runtime itself. Use it for your app too: it's already distributed-system aware.

tractor.log

get_logger

get_console_log

Note

The TRACTOR_LOGLEVEL env var overrides any caller-passed loglevel (e.g. to open_root_actor()) so you can crank console verbosity without touching code; subactors inherit the root's level by default.

/explain/architecture for the transport/server internals, /api/discovery for how channel addresses get registered and found, and /api/msg for the codec layer every channel speaks.