Summary

  • David Cheriton’s February 1988 RFC 1045 specified VMTP, an experimental transaction transport aimed at request-response work such as remote procedure calls. Its transaction identity combined Client, a 32-bit Transaction number and a forwarding count; server state suppressed repeated requests.
  • When a response was marked idempotent, a lost answer led the client to resend the request and the server to regenerate the answer. For a response requiring preservation, the server kept a copy or waited for acknowledgment before releasing it. The current-time example made the tradeoff vivid: a second query could give a newer answer than a saved first one.

Imagine asking a computer for the time, receiving silence, and trying again. A reply copied from the first attempt could already be stale. A new look at the clock is useful. That mundane choice sits at the center of RFC 1045, David Cheriton’s February 1988 specification for the Versatile Message Transaction Protocol. VMTP was designed for request-and-response work, including remote procedure calls, over a datagram service where packets might vanish. Its answer to disappearance was to ask what kind of work the server had done.

The name of a transaction had several pieces. Within an entity domain, VMTP used a Client identifier, a Transaction number and a ForwardCount. The 32-bit number began at a random value when the Client entity was created and normally advanced after each transaction. The four-bit ForwardCount stayed at zero unless a request was forwarded. A server that had already seen the same coordinates kept a client state record and recognized another copy as a duplicate. This was the protocol’s ticket desk: before starting another job, check whose ticket it is and whether this visit is the same one.

The ticket desk needed memory. A server normally retained its state for a while after sending a response, so a delayed duplicate would not send the application back to work. If it had no state for a client, the specification offered different ways to proceed. It could Probe the client’s management module for its current transaction number. It could infer that a request was new if its records had covered the maximum packet lifetime plus retry time and the server had stayed up. Or it could redo a known idempotent operation safely. Those alternatives show how much is hidden inside the innocent word retry: a server must know what it remembers and how long old packets can loiter.

Then came the fork. VMTP could mark a Response idempotent with its datagram-message flag. In that case, the server did not keep a copy of the old response. If the answer disappeared, the Client retransmitted the Request. The server passed that latest request to the application again, which regenerated a response by repeating the operation. Older delayed requests from the same client were discarded. The current-time question is Cheriton’s example: repeating it gets the time now, while a cached copy says what time it was when the first answer was made.

For a response that needed preservation, VMTP made the server carry a different burden. It had to retain a copy, including a copy-on-write option, or keep the application from continuing until the response was acknowledged. A ledger update and a clock reading are different guests at the retry counter. Repeating the first could do the job twice; repeating the second simply refreshes the fact. The protocol could economize on memory where work was safely repeatable, and spend memory or waiting time where one result had to remain the result.

VMTP also trimmed the cost of ordinary retransmission. In low-loss conditions a retry could send only a message control block rather than the entire segment, and the other side could request missing data selectively. A later Request could acknowledge earlier Responses in the protocol’s sense, allowing state to be released. These details reveal why the design treated memory, bandwidth and time as a joint budget. Storing every reply indefinitely would be easy to specify and expensive to run; repeating every operation would be cheap to store and dangerous to promise.

There is a quiet joke in the clock example. The server can be meticulous, file away a perfect copy of an answer, and still return worse information than the lazy clerk who asks the clock again. But the joke has a guardrail: only work known to be safe to redo belongs on that side of the desk. VMTP’s identifiers, server records and latest-transaction rule guarded the retry path; the application’s operation determined whether repeating it was a bargain or a blunder.

RFC 1045 recorded the proposed protocol in February 1988. Its enduring historical value is the way it made a lost reply a question about responsibility. Who keeps the answer? Who performs the work a second time? Who remembers which request came first? Those are operational choices hidden behind every cheerful “try again” button. In VMTP, even the clock had to be consulted by the right transaction.