ipc-communication-patterns

license	Apache-2.0
name	ipc-communication-patterns
description	Comprehensive reference for inter-process communication mechanisms -- every way processes can talk on a computer. Covers sockets (TCP, UDP, Unix domain), WebSockets, SSE, pipes (named/anonymous), shared memory (mmap, shm_open), message queues, signals, D-Bus, XPC (macOS), gRPC, REST, stdin/stdout, file-based coordination, and clipboard. Performance benchmarks, platform availability, and code examples for each. Special focus on which IPC works best for AI agent coordination. Activate on: "IPC", "inter-process communication", "process communication", "how do I talk between processes", "Unix socket vs TCP", "shared memory", "named pipe", "WebSocket vs SSE", "gRPC vs REST", "agent coordination IPC", "XPC service", "message passing", "stdout pipe", "D-Bus", "mmap". NOT for: distributed systems design (use distributed-systems), network protocol design (use networking), message queue infrastructure like Kafka (use data-pipeline-engineer).
allowed-tools	Read,Write,Edit,Bash,Glob,Grep,WebSearch,WebFetch
metadata	{"category":"Systems & Infrastructure","tags":["ipc","sockets","pipes","shared-memory","websocket","grpc","unix-domain-socket","xpc","sse","message-queue"],"pairs-with":[{"skill":"agent-interchange-formats","reason":"Defines data formats that ride on top of IPC channels"},{"skill":"daemon-development","reason":"Daemons are the primary consumers of IPC mechanisms"},{"skill":"multi-agent-coordination","reason":"Agent coordination requires choosing the right IPC for the job"},{"skill":"websocket-streaming","reason":"WebSocket is a specialized IPC with its own streaming patterns"}]}
category	Backend & Infrastructure
tags	["ipc","inter-process","communication","message-passing","patterns"]

IPC Communication Patterns

Every way processes can communicate on a computer. This skill provides decision trees for selecting IPC mechanisms, failure diagnostics, and implementation patterns for AI agent coordination.

Decision Points

Primary IPC Selection Tree

Are processes related (parent-child)?
├── YES
│   ├── Need bidirectional? 
│   │   ├── YES → Unix Domain Socket (same machine) | TCP (may cross machines)
│   │   └── NO → Anonymous Pipe (stdin/stdout)
│   └── Simple one-way → Anonymous Pipe
│
└── NO (unrelated processes)
    ├── Same machine only?
    │   ├── YES
    │   │   ├── High throughput (>1GB/s) → Shared Memory + coordination
    │   │   ├── Low latency (<10us) → Unix Domain Socket
    │   │   ├── Typed RPC needed → gRPC over Unix Socket
    │   │   └── Simple messages → Named Pipe | Unix Domain Socket
    │   │
    │   └── NO (cross-machine capable)
    │       ├── Web-compatible → WebSocket | SSE | REST
    │       ├── Streaming data → gRPC streaming | WebSocket
    │       ├── Request-reply → REST/HTTP | gRPC unary
    │       └── Fire-and-forget → UDP
    │
    └── Browser client involved?
        ├── Server → Client only → SSE
        ├── Bidirectional → WebSocket  
        └── Request-reply → REST/HTTP

Performance-Driven Selection

If latency requirement:
├── <1us → Shared Memory (lock-free ring buffer)
├── <10us → Unix Domain Socket | Shared Memory (with locks)
├── <100us → TCP loopback | gRPC
└── <1ms → REST/HTTP acceptable

If throughput requirement:
├── >10GB/s → Shared Memory only option
├── >5GB/s → Unix Domain Socket
├── >1GB/s → TCP | gRPC
└── <1GB/s → Any mechanism works

Agent Architecture Decision Matrix

Agent Communication Pattern → Recommended IPC

Parent spawns child agents:
├── Simple task execution → stdin/stdout pipe
├── Progress reporting needed → Unix Domain Socket
└── Web UI monitoring → stdin/stdout + SSE to browser

Orchestrator + independent agents:
├── Same machine → Unix Domain Socket
├── May scale across machines → gRPC | WebSocket
└── Simple coordination → Named Pipe

Long-running agent services:
├── macOS → XPC Service
├── Linux desktop → D-Bus
└── Cross-platform → Unix Domain Socket | TCP

Failure Modes

Pipe Buffer Deadlock

Detection: Process hangs when writing to stdin while child's stdout buffer is full Symptoms: write() blocks indefinitely, process unresponsive, strace shows blocking on pipe write Root cause: Both stdin and stdout buffers full (~64KB Linux, ~16KB macOS), neither process can proceed Fix: Use async I/O to drain stdout while writing stdin, or separate threads for read/write operations

# Detect: strace shows blocked write to pipe
strace -p <pid> | grep -E