Implement Remote Procedure Call over TCP Sockets

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.