Summary
- TCP preserved an ordered byte stream, not calls or replies. ONC RPC therefore placed each RPC message in one record composed of one or more explicitly counted fragments.
- Every fragment began with a four-byte big-endian marker. Its low 31 bits gave that fragment's data length; its high bit meant only that the record ended after those bytes.
- A complete record supplied framing, not truth: XDR decoding, XID correlation, authentication, procedure acceptance and durable execution remained separate decisions.
Two bytes were not yet a marker
Suppose a server asks its socket for four bytes and receives two. Nothing is malformed. TCP has delivered the first portion of an ordered stream; the other two bytes may arrive in the next read. The parser cannot borrow payload bytes, guess a length or treat the read boundary as punctuation. It must retain the two bytes and wait.
The opposite can happen on the next call to the operating system. One read may return the rest of that marker, its entire fragment, the marker and body of a second fragment, and the beginning of the following RPC message. Reliability does not preserve the sender's write calls or the receiver's read calls as protocol objects.
RFC 793 already described TCP's ordered-octet service and warned that PUSH did not supply a record-boundary marker. The current RFC 9293 still defines TCP as a reliable, in-order byte-stream service conveyed through segments. Segment edges are transport packaging. RPC needed its own grammar above them.
Four bytes carried two permissions
The public ONC RPC specification RFC 1050, published in April 1988, called the mechanism record marking. One RPC message fitted in one RM record, and a record contained one or more fragments. RFC 1057 replaced that document two months later while preserving the same wire form.
Each fragment starts with a four-byte unsigned word in high-to-low byte order. The lower 31 bits state how many data bytes follow for this fragment: any value from zero through 2^31 - 1. The highest bit is Boolean. Zero says that another fragment belongs to the same record. One says that this is the last fragment, so the record ends only after the declared body has been consumed.
The fields grant narrow permissions. The length lets a receiver advance exactly across one fragment. The terminal bit lets it close the surrounding record at that later position. A high bit seen in the header does not end the record before the body, and a body of the declared length does not end the record when the bit is zero.
The receiver rebuilt a record across arbitrary reads
A robust parser therefore has a small state machine. First it accumulates four marker bytes. It separates the high bit from the length. It then consumes exactly that many stream bytes, even if they arrive in many reads. It adds the data to the current record and examines the saved bit.
If the bit was zero, the next four bytes are another fragment marker in the same record. If the bit was one, the accumulated fragments form one complete RPC message, and the next four bytes begin a new record. The parser never needs a TCP segment boundary. It needs only ordered bytes, exact counts and retained state.
A zero-length fragment is legal under the stated range. It still has a marker and still carries a terminal decision. Conversely, a stream that closes halfway through a declared body has not delivered a short but complete record. It has delivered an incomplete fragment. Record marking can identify the missing boundary; it cannot say whether the remote procedure ran before the connection disappeared.
Fragment was a framing word, not a packet word
The vocabulary is easy to collapse. An RM fragment is not an IP fragment, a TCP segment, a socket write or one XDR field. One RM fragment may span many TCP segments. Several fragment markers and several complete records may share one segment or one receive buffer. Retransmission can change the packet trace while leaving the reconstructed stream identical.
Nor is the last-fragment bit an end-of-file or success flag. A CALL is one RPC message and a REPLY is another. Each receives its own RM record when carried over TCP. The terminal bit says where that encoded message stops. It does not say that a program number exists, that credentials passed, that arguments decoded, that a procedure committed, or that a reply reached durable storage.
This is the practical answer to the old temptation to read PSH as punctuation. PUSH can influence when available bytes move. Record marking tells an RPC parser how many bytes belong to the next framing unit and when the unit is complete. Timing and grammar occupy different layers.
The marker deliberately stood outside XDR
RPC messages themselves are described with External Data Representation. RFC 4506 defines XDR's canonical values, lengths, padding and type structure. A decoder needs that shared representation to understand a CALL or REPLY.
Yet the record-marker specifications explicitly say their four-byte header is not in XDR standard form. Its byte order resembles an XDR unsigned integer, but its job precedes decoding the enclosed RPC message. If framing depended on already having decoded the whole value, the stream parser would need the answer it was trying to discover.
The separation creates two useful failures. A receiver can reject an impossible or excessive framing claim before interpreting a procedure. It can also receive a perfectly framed record whose XDR or RPC contents are invalid. “The message ended here” and “the message was well formed” remain different evidence.
Thirty-one bits did not order a two-gigabyte allocation
The length field gives an upper bound for one fragment, not a recommended buffer size and not a maximum for the whole record. Because a record may contain several fragments, the base rule does not publish one cumulative message limit. A literal implementation that allocates every advertised length before applying local policy converts a wire coordinate into remote authority over memory.
Receiver budgets are therefore an operational inference around the standard: cap cumulative record bytes, fragment count, buffered bytes and time; stream or reject according to the RPC program's needs; and stop before an untrusted length exhausts the service. The chosen limits are local. The marker still supplies the auditable facts against which those limits operate.
The same caution applies to error recovery. The RFCs say delimitation can help detect and possibly recover from protocol errors, but they do not standardize a scan for the next plausible four-byte word. Payload can contain any pattern. After a framing violation, closing the connection may be more truthful than treating coincidental bytes as a new record.
The wire rule survived, then met a transport that replaced it
RFC 1831 carried the format onto the Standards Track in 1995. RFC 5531 replaced it in 2009 without an over-the-wire protocol change. The same high bit and 31-bit count endured because they expressed what TCP lacked and no more.
Their authority was transport-specific. RFC 8166 defines RPC-over-RDMA framing with a transport stream and a payload stream. It expressly replaces all other RPC framing, including TCP record marking, even when RDMA itself sits over a transport that otherwise has an RPC framing rule. A dynamic switch must occur between distinct RPC messages and in concert with the transport.
That later boundary clarifies the original design. Record marking was not an eternal property of an RPC procedure. It was the adapter between one message model and one byte-stream transport.
Sources and evidence limits
The closed record consists of RFC 793, RFC 1050, RFC 1057, RFC 1831, RFC 4506, RFC 5531, RFC 8166 and RFC 9293. They establish the format, lineage and layer boundaries. They do not measure current use, certify a library, describe a captured connection or prove the identity, authorization, correctness or outcome of any procedure.
The historical achievement was exact but modest. Four bytes allowed two peers to agree on where an RPC message ended even when every packet and API call divided the stream differently. The mechanism remained dependable because its final bit never claimed that the work inside had finished.
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
