The question I want to explore
An RPC call looks simple to its caller. Underneath it, partial reads, queued writes, timeouts, and disconnects all compete to decide how the request finishes. I want to make that lifecycle easy to inspect.
Design direction
I’d separate framing, connection state, request correlation, and handler execution. A small versioned message format would carry a request ID and bounded payload. Each connection would own its receive state and serialized write queue.
The central rule would be that each accepted local request completes once, through a response or a specific error. A timeout would stop the caller waiting without pretending it undid work already performed by the peer.
Experiments I’d use
I’d test frames split across reads, several frames arriving together, malformed lengths, delayed responses, and disconnects during output. An echo service would make the transport behavior visible before adding application complexity.
For overload, I’d measure queue depth, admitted requests, rejections, and latency together. Bounded buffering matters more here than an impressive concurrency number without a defined workload.