Implementing Remote Procedure Calls

Basic Idea of RPC

• use procedure call to achieve network communication

Goals

• programmability

• identical semantics as local procedure calls

• efficiency

• security

• generality: applications, hardware, programming language agnostic

RPC Overview

• support many data types(use serialization to support complex data types)

• layer of indirection: applications implemented in different languages, run on different hardware could communicate via RPC

Optimizations

Transport Protocols

• piggyback ACKs with response data

• synchronous

Processes

• use a pool of idle processes to serve RPC requests, avoiding process creation and teardown cost

Connection Management

• no explicit setup or teardown, client need to bind before use

Binding

• query grapevine database to bind at runtime

Exceptions and errors

• independent failures (client or server or network may fail)

RPC Today

• datacenters: gRPC, thrift

• HTTP

Summary

• RPC make remote functionality looks like it is local

• performance optimization

• stub, binding

Eliminating Receive Livelock in an Interrupt-driven Kernel

Targeted Applications

• packet processing: routing, firewall, VPN, load balancer

• services via networks

• streaming applications

• network monitoring

Their common properties: high rated, no flow control

Network Stack

• NIC → network driver → network thread → applications

Receive Livelock

• overloaded system spend all time handling interrupts

Alternative Approach: Polling

• software checks for new packets

Solutions: Hybrid Approach

• interrupt when new packets arrive and polling to collect a batch of packets

• remove a layer of queues, processing packets all the way down

• round robin scheduling on tasks

• reserve a portion of cpu time for applications

Summary

• the idea of receive livelock

• hybrid approach with polling & interrupts

• drop tasks ASAP when overloaded