skip to content

When a request reaches an RPC server, how does the dispatcher choose the procedure, and what can fail before that procedure runs?

level: middleimportance: nice to knowfreq 14%

answer

  1. the request names its target
  2. service, version, procedure
  3. lookup before argument decoding
  4. distinct errors, not one

basics

~20 s

The request names its target - a service or program, often a version, and a procedure - and the dispatcher looks it up. An unknown service, version or procedure, or arguments that will not decode, are reported before any handler runs.

solid answer

~50 s

The dispatcher reads the target from the request - a numeric triple in ONC RPC (`prog`, `vers`, `proc`), a method-name string in text protocols - and looks it up in the table of procedures the server registered. Only then can it bind the arguments, because their layout belongs to that procedure. Several things can fail before application code runs: the RPC protocol version or the caller's credentials can be rejected, the service may not be hosted there, the requested version may be unsupported, the procedure may not exist, or the arguments may not decode. A well-designed protocol reports each distinctly - RFC 5531 has `PROG_UNAVAIL`, `PROG_MISMATCH` with the lowest and highest supported versions, `PROC_UNAVAIL` and `GARBAGE_ARGS` - so a client can tell a wrong server from a stale stub from a bad call. An error raised inside the procedure is a different class: that call was dispatched.

go deeper

for a junior

Recall that every RPC request names its target procedure and that the server looks it up before running anything.

for a middle

Walk through dispatch in order - protocol check, authentication, service, version, procedure, argument decoding - and name what each failure means for the caller.

for a senior

Use dispatch errors in diagnosis: a version mismatch after a rollout, garbage arguments from contract drift, and why each means the procedure never ran.

for a principal

Argue for serving several interface versions side by side and for distinct, monitored dispatch errors as part of how an organisation evolves its remote interfaces.

## What a request has to name A server process can host several services, several versions of each, and many procedures per version. So every RPC request carries a **procedure identifier** precise enough to pick exactly one handler. RFC 5531 puts "unique specification of a procedure to be called" first among the requirements of the ONC RPC protocol, and does it with three unsigned integers in the call header: - `prog` - the remote program (a service), from a numbering space IANA administers; - `vers` - the version of that program's protocol the caller speaks; RFC 5531 says version numbers "enable support of both old and new protocols through the same server process"; - `proc` - the procedure within that program version. Text-based protocols use names instead: a JSON-RPC 2.0 request has a `method` string. The idea is the same - a key into a table the server built at start-up when each implementation was **registered**. ## The dispatch steps 1. **Accept the message.** Check that it is a well-formed request in a protocol version the server speaks, and authenticate the caller if the protocol requires it. 2. **Resolve the service and version.** Is this service hosted here, and which of its versions does the request ask for? 3. **Resolve the procedure.** Look the procedure up in that version's table. 4. **Unmarshal the arguments** with that procedure's decoder. In ONC RPC the parameters are encoded in XDR, which is not self-describing, so they cannot be bound until step 3 is done; even with a self-describing format, binding them to parameters needs the procedure. 5. **Invoke** the implementation, then marshal its result or error into the reply. Everything before step 5 happens in RPC machinery, not in application code. ## Failures before the handler runs | Failure | What it usually means | ONC RPC reply (RFC 5531) | |---|---|---| | RPC protocol version unsupported | Client and server speak different RPC protocol revisions | Rejected, `RPC_MISMATCH` with lowest and highest supported | | Caller not authenticated | Bad, expired or too-weak credentials | Rejected, `AUTH_ERROR` with an `auth_stat` reason | | Program not hosted | Wrong server, or the service is not running there | Accepted, `PROG_UNAVAIL` | | Program version unsupported | Client stub newer or older than the server | Accepted, `PROG_MISMATCH` with lowest and highest supported | | Procedure unknown | Usually a client-side protocol or programming error | Accepted, `PROC_UNAVAIL` | | Arguments do not decode | Client and server disagree about the procedure's contract | Accepted, `GARBAGE_ARGS` | RFC 5531 also defines `SYSTEM_ERR` for failures in the server's RPC layer itself, such as a memory allocation failure. Note the split: a **rejected** reply (`MSG_DENIED`) means the call was refused at the RPC level; an **accepted** reply (`MSG_ACCEPTED`) carries either `SUCCESS` or one of the dispatch errors. ## Why the distinctions matter - **Diagnosis.** "Not hosted here" points at deployment or addressing; "version mismatch" at a stale stub; "unknown procedure" at a client bug; "garbage arguments" at contract drift between the two sides. - **Negotiation.** Because `PROG_MISMATCH` and `RPC_MISMATCH` return the supported range, a client can pick a version both sides speak instead of guessing. - **Safety.** Every one of these failures means the procedure did **not** run, which is useful knowledge for the caller - unlike an error from inside the procedure, which may have left work half done. - **Monitoring.** Counting dispatch failures separately from application errors shows a bad rollout before users report it. ## Versions side by side, and procedure 0 Because the version is part of the procedure identifier, one server can keep serving old clients while new ones move to a new version; RFC 5531's example program keeps an original version alongside a newer one that adds a procedure. By convention procedure 0 of every ONC RPC program is a **null procedure** - no arguments, no results, never requiring authentication - which clients use to check that a program and version are reachable and to measure round-trip time. ## Common confusions - Returning an empty success for an unknown procedure hides a contract mismatch and lets the caller believe work was done. - Folding every dispatch failure into one generic error throws away the information the client needs to react. - Treating undecodable arguments as the procedure's own bug misplaces it: the handler never ran.

  • Why does an ONC RPC PROG_MISMATCH reply carry two numbers?
    They are the lowest and highest versions of that program the server supports (RFC 5531's `mismatch_info`). A client can then retry with a version inside the range, or report precisely that its stub is too old or too new, instead of failing with an opaque error.
  • What is procedure 0 used for in ONC RPC programs?
    By convention it is a null procedure: no arguments, no results, and RFC 5531 says it should never require any kind of authentication. Calling it checks that a program and version are reachable and, as RFC 5531's ping example notes, is useful for computing round-trip times.

saying these in an interview costs you the question

  • For an unknown procedure the server should return an empty successful result.
  • One generic error code is enough for every failure before the handler runs.
  • Undecodable arguments are the procedure's own bug, reported like any handler error.
  • A version mismatch means the server must be rolled back immediately.
  • If dispatch failed, the procedure may still have partly run.