local versus network IPC
Two processes that need to talk might be sitting side by side on the same computer, or they might be oceans apart on different machines. The mechanisms look deceptively similar — you can use sockets for both — but the realities underneath are profoundly different, and confusing the two is a common source of bugs and bad design. This entry draws the line so you know which world you are in.
Local IPC stays inside one machine and one kernel. Pipes, FIFOs, shared memory, message queues, signals, and Unix-domain sockets all live here. Their data never touches a network: bytes are copied through kernel memory, or, with shared memory, not copied at all. So local IPC is fast (microseconds or less), reliable (no packets to lose on the way), and ordered, and it can do machine-only tricks like passing file descriptors and reading a peer's credentials. The participants share a clock, a filesystem, and the same operating system. Network IPC, by contrast, sends bytes across a wire (or wireless) between separate machines, through the IP stack, network cards, switches, and routers. Now you face latency measured in milliseconds, packets that can be lost, delayed, duplicated, or reordered, no shared memory, different machines that may have different byte orders, and a peer that can vanish without telling you.
The practical upshot: choose local IPC when both parties are on one host — it is simpler and far faster, and shared memory or a Unix-domain socket beats looping a TCP connection back to yourself. Reach for network IPC only when you genuinely must cross machines, and then accept its tax: you must serialize data into an agreed wire format, handle partial reads and lost connections, deal with byte order, and design for failure. The seductive trap is that a Unix-domain socket and a TCP socket use almost the same API, which makes it easy to forget that one never leaves the building and the other braves the open internet. Cross-machine networking is its own field; this entry is only the signpost that says where local IPC ends.
Same machine: socket(AF_UNIX, ...) — bytes copied in-kernel, microseconds, no loss, can pass fds. Different machines: socket(AF_INET, ...) — bytes cross the network, milliseconds, packets may be lost/reordered, must handle byte order and failures.
Almost the same API, two different worlds: one stays in the kernel, the other braves the wire.
Do not reach for the network just because the socket API supports it. Two processes on one host should use local IPC — a Unix-domain socket or shared memory — which is faster and simpler than a TCP loopback and cannot drop packets.