Erlang and Distributed Systems

An Erlang node is identified by a name of the form shortname@host (or longname@fully.qualified.host in -name mode). When a node starts in distributed mode, it registers with a small local daemon called EPMD (Erlang Port Mapper Daemon, listening on TCP port 4369 by default), which maps node names to the dynamic port each node's distribution listener is bound to. Two nodes can only connect if they share the same Erlang cookie, an atom-valued shared secret used as a lightweight authentication token; net_adm:ping('other@host') is the conventional way to establish and verify a connection.

Once nodes are connected, Erlang's messaging is location-transparent: Pid ! Msg uses exactly the same syntax whether Pid identifies a process on the local node or a process running on a remote node, and spawn/2,3,4 can start a process directly on a remote node by passing its name as the first argument. rpc:call(Node, Module, Function, Args) layers a synchronous request/response convenience on top of this same messaging, letting you invoke a function on a remote node and block for its result the way you would call a local function.

The global module extends local process registration across the whole cluster: global:register_name(Name, Pid) makes a process reachable by one unique name that resolves consistently from any connected node, and global:whereis_name(Name) looks it up. To react to connectivity loss, a process can call monitor_node(Node, true) to receive a {nodedown, Node} message when the connection to that specific remote node drops, which is how supervisors and cluster managers detect and respond to partitions.

By default, distributed Erlang forms a full mesh: every connected node maintains a direct TCP connection to every other node. That works well for clusters of a handful to a few dozen nodes, but connection and heartbeat overhead grows quadratically, so it doesn't scale gracefully to hundreds of nodes without alternative topologies such as those offered by Partisan. It's also worth noting that distributed Erlang's default transport is unencrypted and authenticated only by the shared cookie, so production deployments crossing untrusted networks typically enable inet_tls_dist for certificate-based encryption instead of relying on the cookie alone.