Network

Network is the realization substrate for interaction across link, network, transport, and application protocol boundaries.

Network mechanisms realize interaction edges, but they are not the definition of interaction. Interaction also occurs locally between processes, threads, runtime tasks, actors, CPU cores, memory cells, and synchronization primitives. Networked interaction is one important family of realization.

This note specializes interaction for network substrates. Use interaction for the general boundary-relative model of observers, modes, semantic roles, and guarantees; use this note for how those edges are realized through protocol layers and physical links.

Application Interaction from Async Send/Receive

At the bottom of the software network stack, interaction can be modeled as asynchronous send and receive:

A send operation hands data to a local protocol boundary. Completion usually means local acceptance, not remote receipt, processing, or commitment.
A receive operation observes data that has already been admitted by the local protocol stack.

Protocol layers add structure to this minimal edge:

Ethernet adds a link-local frame as an atomic transmission unit. Failed or corrupt frames are generally dropped; recovery, if needed, is provided by another layer.
IP adds network-level addressing and routing across links. It provides best-effort datagrams, not reliable end-to-end delivery.
UDP adds transport demultiplexing through ports and preserves datagram boundaries, but does not add ordering, reliability, or congestion control.
TCP adds ordering, retransmission, flow control, and congestion control, forming a full-duplex connection with an ordered byte stream in each direction. It orders bytes within a connection, not application messages, and TCP acknowledgments do not imply application processing or durable commit.
HTTP, RPC, WebSockets, gRPC, and custom protocols add application-level framing, correlation, multiplexing, status, metadata, request/reply, and streaming semantics.
Queues, logs, topics, and brokers reify channel state as system entities. Clients typically interact with them through lower-level request/reply protocols, thereby implementing higher-level publish/consume, subscription, cursor, retention, and delivery semantics.
Application flows compose those protocols into domain-level interactions and business transactions involving services, humans, agents, policies, entities, and processes.

This ladder is not a strict hierarchy of concepts. The same interaction edge shape can reappear at different layers. UDP multicast and a Kafka topic are both one-to-many publication configurations at different realization boundaries, with very different addressing, durability, ordering, retention, and acknowledgment semantics.

Link and Physical Realization

Application protocols can also be followed downward. A single application request may lower into framed bytes, transport segments, network packets, link-layer frames, media-access decisions, encoded symbols, clocking, electrical or optical signal changes, buffering, and retransmission or error-handling rules at several layers.

At a link boundary, a frame transmission may be treated as the interaction unit. The link can add local addressing, framing, error detection, arbitration, pause or flow-control behavior, and sometimes link-local acknowledgment or retry. At the physical boundary, the same frame is realized through signal encoding, timing, modulation, propagation, reception, and decoding. These lower-layer interactions realize the higher protocol without inheriting its semantic meaning. A received symbol or valid frame is not an HTTP response, a broker publish, or a committed domain transition.

This is why protocol guarantees must be mapped to the boundary where they hold. A physical signal can be detected, a frame can pass an error check, a packet can be routed, a TCP peer can acknowledge bytes, an RPC layer can correlate a response, and an application observer can commit a transition. Those are different claims joined by protocol layering, not one undifferentiated notion of delivery.

RPC over TCP

TCP realizes a bidirectional ordered byte-stream interaction edge. It does not provide application messages, method calls, request/reply correlation, or domain commitment.

RPC coordinates atop TCP by adding an application-level protocol over the byte stream:

Framing: divides the byte stream into application messages. Without framing, a receiver only sees bytes; it cannot know where one request or response ends and the next begins.
Correlation: associates a response with the request that caused it. This is required when multiple calls are in flight over one connection.
Multiplexing and demultiplexing: allow several logical request/reply interactions to share one stream or connection.
Dispatch: names the operation, method, route, actor, service, or procedure the receiver should invoke.
Payload shape: declares how request and response values are encoded, decoded, validated, and interpreted.
Status and errors: distinguish success, application rejection, protocol error, timeout, cancellation, and transport failure.
Metadata: carries headers, deadlines, authentication, tracing, content type, compression, or feature negotiation.

These additions realize application-level request/reply over a lower-level stream/session edge. The request may then be interpreted semantically as a command, query, subscription request, negotiation, or another input role by the receiving observer.

The boundary of each guarantee must remain explicit:

A successful socket send usually means local TCP acceptance.
A TCP acknowledgment means the peer TCP stack acknowledged bytes in the stream.
A complete RPC response means the application protocol produced a correlated reply.
A successful command response means only what that application defines: accepted, validated, processed, persisted, committed, scheduled, or something narrower.

RPC therefore coordinates bytes into messages and messages into request/reply interactions, but it does not by itself prove that a domain transition committed. That requires observer-relative interpretation, validation, persistence, and an explicit commitment boundary.

Mapping Guarantees

Network guarantees must be mapped to the boundary where they hold:

What is addressed?
What unit is delivered?
What does acknowledgment mean?
What ordering is preserved?
What can fail independently?
What is durable or replayable?
What interpretation turns transmitted values into commands, queries, events, observations, or decisions?

Network behavior does not automatically equal domain commitment. The receiving observer still interprets the value relative to its boundary, validates it, and may or may not commit a transition.

Network partitions expose the distinction between safety and liveness. A system may preserve a consistency claim by refusing progress across the partition, or preserve availability by accepting progress whose global order or freshness cannot yet be known. The CAP theorem is the named form of this tradeoff for linearizable shared data.