i. NOTE: at this time lower levels of software (e.g. PUP) not well optimized
ii. NOTE: bigger problem is lack of routing at lower level; only works for a single network with no routers
i. QUESTION: why not?
ii. ANSWER: cost is so high that you are only measuring encryption cost, not intrinsic cost of RPC model
i. QUESTION: what was result?
ii. ANSWER: still the case today. Look at Windows, Unix
1. RPC used for DS queries, small request/response
2. Look at DNS queries
3. Mail messages were a lot smaller then (no mime/attachements)
i. QUESTION: can you do the same thing in DNS?
ii. ANSWER: essentially same model, but not dynamic. MS uses dynamic DNS as a name service for this in a limited way, and a DS in genereal – exact same model
i. QUESTION: why not put HTTP on to of RPC?
ii. QUESTION: why not used on Internet?
1. A: failures common, RPC doesnÕt deal with failures well
2. A: internet deals with heterogeneous systems. RPC requires code generator for packets, means porting software or implementing something big and general purpose when all you need in any once case is a small piece of work.
i. A: replication for reliability. Indirection for flexibility – want to upgrade the machine, move service to another machine. Where do you get an IP address?
i. Distributed programming
1. QUESTION: why important? improve performance by distributed code to different machines
ii. Hard to write distributed programs using messages
1. Like writing in ASM
iii. How do you make an efficient high-level communication mechanism?
1. Similar to using compiler instead of ASM, or scripting language instead of C
iv. Target environment: local area network, closely-coupled computation, generally reliable
i. Find the right paradigm for distributed computing
ii. Fine-tune the semantics
1. Make it as powerful as possible so donÕt need to layer mechanism above it
iii. Implementation choices for efficiency
i. Still has problems of data & argumenet passing
i. Difficult to make fast
ii. Hard to program – memory classes not exposed in language
i. Is the common case
ii. Can use fork/join for asynchronous communication
i. Client, client stub, runtime, server stub, server
ii. Name server
iii. IDL compiler - Lupine
i. DonÕt allow
ii. Marshall automatically
i. No time-outs
ii. Return communication failures as exceptional conditions
1. QUESTION: What does this mean for RPC packages in C?
2. QUESTION: how does this impact programming?
a. New failure modes
b. Depends on whether programmers already handle exceptions
3. QUESTION: What should a program do on failure?
i. Convert between endian-ness
ii. Convert between pointer sizes
i. Naming: type (interface name) and instance (host name / service name for replicated services)
ii. QUESTION: What do you want from naming?
i. Contact a name service:
a. Entry for each type
i. Lists instances of the type
b. Entry for each instance
i. Addressing information for host
c. QUETSION: What about DNS?
i. DNS for mail services
ii. LDAP in Windows
i. ExportInterface registers information with grapevine automatically when server starts up
ii. RPC runtime maintains a table mapping interface name to dispatch procedure & 32 bit instance/incarnation identifier (changes after reboot)
i. ImportInterface asks grapevine for addressing information (or uses provided name/address)
1. When several available, client runtime gets all, tries them in useful order
ii. Runtime on client RPC to server to receive binding association (unique identifier/incarnation number)
i. Binding does not create state on server ˆ scalable
ii. Bindings broken when server crashes ˆ automatically informs client
iii. Access controls on grapevine limits who can register an interface
1. QUESTION: Should it limit who can import?
a. Can learn of imports other ways, e.g. port scanning
i. Minimize latency of calls
ii. Minimize state needed on server for handling many clients
iii. Provide useful semantics:
1. On success, exactly one execution
2. On exception, zero or one execution
a. QUESTION: Why? Impossibility result
3. No timeouts
a. QUESTION: Good? Bad? What is user experience?
1. Optimize for common case:
a. Request & reply happen in a single packet
b. Reply takes less than a roundtrip of computation
2. Piggyback ackÕs on subsequent packet
3. Leverage protocol properties
a. Only one outstanding request per client on an interface ˆ no sliding window
b. Not need to establish connection; server just remembers highest # request from client to detect duplicates
c. Sender of data packet resends until ACKd, by next call or explicit (if call takes longer)
v. Handle complex case simply
1. Multiple-packet request/reply explicitly ACK every non-terminating packet before sending next packet
a. Only last packet must be buffered on either side
b. Use other protocols for bulk transfer
vi. Avoid expensive process creation for handling requests
1. Server uses separate process / concurrent request (no threads)
2. Creates pool of processes to avoid expensive creation cost on call
3. Hints to client what process to request to use same process for all requests in a conversation
a. QUESTION: What are the implications? Each call independent? No state across calls? Servers must share shared dynamic state across processes?
i. Complexity of using system
ii. Amount of code to solve a problem
iii. Fault tolerance
v. Scalability / throughput / simultaneous clients
i. Performance of calls relative to procedure call and messaging latency
ii. What about compared to bare message passing?
i. Optimize for the common case
1. Avoid unnecessary complexity
2. Take advantage of communication pattern – e.g. synchronous request/reply
ii. Handle the uncommon case correctly & simply
iii. Re-use a known-good idea
iv. Layer of indirection
1. Stubs hide complexity, multiplexing
v. Scalability via stateless / reduced state
1. Server only holds one number per client
i. QUESTION: What should you do on failure? Retry ? How many times? How long should you wait?
i. Procedure call level may be too low; message formats for internet protocols may encourage better separation between code and protocol
ii. Encourages synchronous round trips; hard to batch requests that can be overlapped
iii. Difficult to revise interfaces; is handled but leads to ugly code on server
iv. Generally language specific