Lecture #18

Administrivia

• elided

Our Story So Far

• networking
  • layers of protocol (OSI: 7-layers)
  • TCP/IP & UDP/IP won the wars
  • Berkeley sockets: multiple protocol support
  • can use sockets for IPC on single machine
    • Unix Domain
    • TCP/IP & UDP/IP on loopback address
  • 2 kinds of socket:
    1. stream: read()/write()
    2. datagram: send()/recv() or sendto()/recvfrom()`

Client-Server Systems

• socket communication is bidirectional

• difference between client & server: networking level

  • server: passive (accepts incoming connections)
  • client: active (initiates outgoing connections)

• difference between client & server: application level

  • server provides some well-defined service, e.g.
    • map name to IP address
    • current time of day
    • run user shell on this machine
    • send file
    • play global thermonuclear war

Remote Procedure Calls

• API: application programming interface

• RPC: API that looks like function call

  • 2 components:
    1. server
    2. client library linked into application program

• service discovery

• server:

  • accept request
  • unmarshal (de-serialize) request & args
  • perform requested action
  • marshal (serialize) response
  • send response back to client

• client library: "stub" to manage communication with server

  • marshal: "serialize"
  • unmarshal: "de-serialize"

• RPC is a leaky abstraction

  • networking lag/timeout
  • network failures (partition)

• XML/RPC (evolved into SOAP: Simplified Object Access Protocol)

  • XML: encoding (serialization)
  • HTTP: transport mechanism (layer)

• See also: JSON-RPC

  • REST: Representational State Transfer

• Google protobufs (serialization) & stubby (transport)

• CRUD application: Create, Read, Update, Delete

• RPC is a generic term (abstraction)

  • multiple implementations
    • ONC-RPC (Open Network Computing, formerly Sun-RPC)
      • developed for NFS (network filesystem)
    • RPC over HTTP (XML or JSON): REST
    • Erlang
    • Google stubby/protobufs
    • roll your own

• Sun RPC (AKA ONC-RPC)

  • original (?) -- developed by Sun
  • developed for NFS
    • original (?) remote-mounted filesystem
    • abstracton: looks like local filesystem (mostly)
  • protocol (exchanging messages)
    • based on Unix/C calling conventions
  • rpcgen tool
  • interface definition language (IDL)
    • C-like syntax
  • works with both TCP & UDP transport layers
  • service discovery
    • port mapper (port 111)
    • rpcbind (directory service)

External Data Representation (XDR)

• data serialization
  • *.x files
  • function library
  • independent of transport layer
  • base unit: 4 bytes (32 bits), big endian
    • smaller datatypes occupy 4 bytes after encoding
    • strings, etc. padded to 4-byte boundaries
  • floating-point numbers: IEEE 754

rpcinfo

• rpcinfo -p

rpcgen (ONC RPC_

• protocol compiler: generate server & client stubs

• input: RPCL (RPC Language)

• rpcgen prog.x generates:

  • pro_clnt.c
  • prog_svc.c
  • prog_xdr.c
  • prog.h
  • stubs
    • prog_server.c
    • prog_client.c

• server side: register callable procedures

  • rpc_reg()
  • rpc_call()

• client side

  • clnt_create()/clnt_create_timed()
  • svc_create()
  • clnt_call()

Memory Hierarchy

• cache (higher level: larger but slower)
  • L1 (level 1): ~1 to 2 clock cycles to access
  • L2: ~7 cycles
  • L3
• main memory: ~100 cycles

• disk: ~8M cycles (seek)

• cache-aware programming (lecture #1)

  • array processing

• mutex lock/unlock: ~25 ns (~25 cycles)

• numbers are subject to change

Main Memory

TODO: diagram

• non-VM (virtual memory) system

  • multiple processes loaded into memory at different locations
  • concurrency: more efficient use of CPU
    • processes waiting on I/O sleep while ready processes run

• physical address

  • all memory (actual memory chips)
  • I/O-mapped devices

• problems with physical address:

  • main(): fixed address
  • all functions: call {addr}
  • global memory

• solution 1: linkage editing

  • program load time: edit all addresses relative to start-of-process address
    • requires symbol table in executable file to list addresses to edit

• solution 2: relative branch

  • all data is relative to current position (program counter + offset, or stack pointer + offset)
  • doesn't work for global data

• solution 3: process-specific base address (segment register)

  • kernel must reset segment register on context switch