Implement Remote Procedure Call over TCP Sockets

Topic Overview

Procedures Across a Wire

RPC marshals function name and arguments into bytes, sends over TCP, executes on server, and returns results. JSON-RPC and gRPC are industrial versions; your task builds the skeleton by hand.

Request Frame

Minimal layout:

• length prefix
• procedure id
• serialized args

For example, ADD(2, 3) might send 0x00 0x07 length plus opcode 1 and two int32 values, expecting 5 back.

Why This Matters in Production

This hand-rolled marshal/send/receive loop is exactly the problem gRPC and Protocol Buffers were built to solve at Google scale, and the raw-struct approach shown here is precisely why real RPC systems must worry about endianness and struct-padding mismatches between client and server architectures. The partial-read/partial-write handling this task calls out is a genuine correctness requirement: naive single recv() calls assuming a full struct arrives atomically are a well-known source of intermittent bugs over real TCP connections, where the OS is free to deliver data in fragments.

Debugging Checklist

Before you call the implementation done, walk failure modes on purpose. Test empty structures, single-element edge cases, maximum concurrency, and errno paths that must not crash the program. OS code usually fails in production when happy-path tests pass but invariants break under contention or memory pressure.

Implementation Notes

Keep structures small and name fields after kernel counterparts when possible. That lets you read man pages and kernel source side by side while you work. Print observable events during development; remove noisy logs once tests pass reliably.

For This Exercise

You will implement client stub and server dispatcher over sockets you already built. The task asks you to handle malformed packets without crashing the server loop.

Your Task

Build a minimal remote procedure call system. Client stubs make a remote call look like a local function. Each stub marshals the procedure id and arguments into a binary request frame and sends it over a stream socket. The server unmarshals the frame, dispatches with a switch, and sends back a response frame. The parent process is the client and a forked child is the server. They talk over a socketpair(AF_UNIX, SOCK_STREAM), which runs everywhere; the same code works unchanged over a TCP connection.

Wire format (all integers big-endian, "network byte order")

Request: u32 length (bytes that follow), u8 procedure, u8 argc, then argc × i64 arguments. Response: u32 length, u8 status, then an i64 result only when status is 0.

Input

One call per line: call NAME ARG... with decimal integer arguments, or call #ID ARG... to send a raw procedure id.

Output

For each call:

cCopy
Loading…

The first line is NAME(ARGS) = RESULT or NAME(ARGS) -> error: MESSAGE, using the status meanings above. A raw call is shown as #ID(...). Arguments are separated by , . At the end, the client shuts down its sending side. The server exits with status = the number of requests it handled, and the client prints server handled N calls.

Example

Input:

cCopy
Loading…

Output:

cCopy
Loading…

Requirements

1. Marshal with explicit shifts ((v >> 56) & 0xff, …), never by write-ing a struct. The bytes must be identical on every machine.
2. Read exactly length bytes, looping over short reads, before decoding a frame.

Hidden tests cover negative numbers (two's complement on the wire), mul and neg, sum with zero and many arguments, a wrong argument count, and an unknown procedure id.