Send a request across a stream of bytes

You can now follow an operation inside one engine. To use that engine from another computer, the application must send a request and receive an answer. Start with one connection and one request at a time; concurrent requests come later.

The application wants to send GET 27, then GET 46. These are two messages to the application. The network interface we will use does not preserve that distinction.

Give the receiver a boundary

TCP provides an ordered byte stream while the connection works. A read may return part of a request, exactly one request, or bytes belonging to several requests. A packet boundary is not an application message boundary.

For a small teaching protocol, put a four-byte unsigned length before each UTF-8 payload. Specify that the length uses big-endian byte order and counts payload bytes, not characters. The sender’s first message is four length bytes representing 6, followed by the six bytes of GET 27.

Read the header
Collect all four length bytes, even if several reads are needed.
Read the payload
The length is 6. Collect exactly six payload bytes.
Start the next message
Any remaining bytes belong to the next header.

The receiver reconstructs messages from lengths. It does not infer them from individual reads.

If the first read returns two header bytes, keep them and wait for the other two. If a later read contains the remaining header, the entire payload, and the beginning of the next header, consume only what the current message requires.

This rule is called framing. Reject lengths above a chosen limit before allocating memory. If the connection ends halfway through a message, report an incomplete message rather than executing its fragment. Sending also requires care: an API can accept fewer bytes than requested, so the caller must send the remainder.

Count trips as well as bytes

Suppose a request and response together transfer 2 KB over a link that can carry 100 MB each second. Transmitting the bytes would take about 0.02 milliseconds under these idealized units. If a round trip takes 20 milliseconds, distance and waiting dominate this tiny exchange.

Combining independent requests can reduce trips. It also needs response framing and a way to associate each answer with its request. Larger batches can make the first answer wait longer.

Predict what the server received

The sender reports that it accepted all request bytes. The connection then closes before a response arrives. Does the client know the purchase committed?

Work through the missing response

No. Acceptance by the local networking API is not a database acknowledgment. The server might never have received the complete request; it might have rejected it; or it might have committed and lost the response. TCP orders bytes but does not settle this application-level uncertainty.

Framing lets the server recognize a complete request. The next page gives that request an identity so a retry need not create a second purchase.

Source: TCP’s byte-stream semantics and interface in RFC 9293. The length-prefixed protocol here is an educational design, not PostgreSQL’s wire format.

Extended reference

The extended chapter preserves the original technical coverage, additional examples, and citations. The explanation above supplies the concepts needed for this page; the reference develops the specialist cases.

Find a section from the original chapter