Recap

n Many different networking problems

n Approach: layered protocols
n Protocols:
TCP & RPC n Calling interface

n Depends on lower transport interfaces

n Communicates with peer

Arvind Krishnamurthy n Internet Protocol:

n No sequencing, stateless, unreliable
Spring 2001 n Host-to-host
n Addressing and naming
n Fragmentation
n Imposes limits: TTL, message size

TCP Overall Features

n Connection oriented n Reliable
Sequence numbers (per byte basis)
End-to-end reliable
n
n open n Acknowledgements
Flow controlled close
n n Timeout/retransmit
write
push n Flow control
read n “sliding window protocol”
n Purpose: pipeline communication through overlap

n Multiplexing
n Several connections to be open (sockets: host, port number)

Send packet n Connection-based: state kept at both ends

Recv packet

n Out of band data: “urgent”

Sequence Space Interesting Events

n Sender sequence space divided into: n New data from user:
n Sent and acknowledged n Buffer
n Sent and not acknowledged n Send if “lots” of data and in window (or push or urgent)
n Not sent and “In-window”: promise of buffer space on receiver
n Not sent and not inside the window n Data (segment) arrives at the receiver:
n Data TCP has not even seen yet (not received from user) n Check sequence number
n Receiver sequence space divided into: n Buffer data if new data, else throw away duplicates
n Data given to the user (not TCP’s responsibility any more) n Send an acknowledgement by sending back sequence numbers
n Data that has been acknowledged but not given to user n Acknowledgement sequence space should be contiguous

n Data not acknowledged n Might result in a “bunched acknowledgement”

n Rest of the window n Give data to user

1
 Other Issues Connections
n When to retransmit? n Setup and teardown is always tricky
n No good fixed time! n Requires three-way handshakes
Must compute on the fly
n
n Setup:
n Keep a running weighted average
n Open request packet (SYN, initial sequence number)
n Give more weight to recent measurements
n Acknowledgement (SYN, own sequence number, ack number)
n Acknowledgement of the acknowledgement
n Window management? n SYN occupies 1 byte of sequence space
n Windows can decay
n Lots of scenarios:
n Receiver: only send large increments
n What if packets get lost?
n Sender: wait for large windows
n What if machines go up and down?
n Cannot reuse sequence number if there are some old live data

Remote Procedure Call RPC

n Classic RPC System: Birrell, Nelson n Characteristics:
n Different kind of protocol from TCP n Synchronous
Little data
Not designed for one-way flow
n
n
n Performance dominated by latency issues
n Request-response style of interaction
n Lightweight
n Which one is better?
n Not a layered protocol; all-in-one solution
n Message based model, or
n Ideally suited for single ethernet/LAN; no long distance
n Procedure based model
communication, no round-trip calculation, no sliding window, etc.
n Easier programming model
n Very little state associated with it n Depends on application; clearly not useful for video streaming, but

n Procedure model: useful for remote file access

n Execute code on remote machine
n Package arguments, send it to remote machine, do computation, n When would you want to execute procedure call on a remote machine?
return result

Remote procedure call Implementation (cont’d)

n Call a procedure on a remote machine n Client stub
n Client calls: remoteFileSys->Read (“foo”) n build message
n Translated into call on server: fileSys->Read(“foo”) n send message
n wait for response
n Implementation: (1) request-response message passing (2) “stub” n unpack reply
provides glue on client/server
n return result
call bundle args send
Client ClientStub PacketHandler n Server stub
return unbundle retvals receive n create N threads to wait for work to do
network n loop: wait for command
transport
decode and unpack request parameters
return bundle retvals send
call procedure
Server ServerStub PacketHandler
call unbundle args receive
build reply message with results
send reply

2
 Implementation issues Locating the server
n Stub generator --- generates stub automatically. n How does the client know which mbox to send to?
n For this, only need procedure signature --- types of arguments,
return value. n Binding: use central registry server
n Generates code on client to pack message, send it off
n On server to unpack message, call procedure
n Each server registers “types+instance” of the service, lists all procedure
calls supported.
n Input: interface definitions in an interface definition
language (IDL) n Access control at the registry protects clients from rogue servers
n Output: stub code in the appropriate source language (C,
C++, Java, …) n Server builds table including all exported RPC interfaces and interface
n Examples of modern RPC systems: ID (interface ID also used to detect calls to old interfaces)
n CORBA (Common Object Request Broker Architecture)
n DCOM (Distributed COM)

RPC semantics of failures Performance

n Client can’t locate the server n One packet for args, one for results
n Procedure returns error upon binding time n Each packet must be acknowledged
n If packet is not acknowledged, sender retransmits
Piggyback the acknowledgement to the result
Request message lost
n
n
n Result acknowledges the request
n Caller retransmits, callee uses request sequence number to identify
n Next request acknowledge the previous result
duplicate requests
n There is a sequence number; server keeps around this (unique call

ids)
n Reply message lost n Server state: table of call ids; can be flushed in a while

n Callee retransmits, caller uses the corresponding request sequence n Duplicate packets
number to identify duplicate replies n Keeps the result around
n Retransmit the old result for the same request
Scenarios: lost server response, long call (client occasionally prods),
n Server crash: use another one. Client crash: log RPC calls n

acknowledges the second request, client just prods from that point on
and then ask server to kill orphans upon recovery.

Performance (contd.)
n Large messages: (file blocks not fitting in a packet)
n Acknowledge per packet
n Doubles packets, adds latency
n Alternative: stream data, send back a bit-mask of
acknowledgements
n Extra complexity is probably worth-while
n Process structure?
n Dedicate to a certain client

n Multiple server processes

n Performance: 1.2ms/call in original RPC implementation

n 2000-5000 instructions
n 100us (best today?)
n 3-4x kernel call