1. Distributed OS

2. Commn. Primitives
High level construct with which program use underlying network
2 commn. Models : Msg Passing & RPC
Msg Passing – 2 primitives: SEND & RECEIVE
Design issues :
buffered option – msg copied 3 times
unbuffered option : program issuing SEND should avoid resuing user buffer till msg. is transmitted

3. Commn. Primitives
Non-blocking primitives:SEND returns control to user process as soon as msg is copied to kernel buffer
Flexibile to perform computation & commn.
Complex : programs may become time dependent, difficult to debug
Blocking primitives: SEND will not return control until msg. is sent (unreliable blocking), or until ack. Received (reliable blocking)
Corres. RECEIVE will not return control till msg. is copied to user buffer (unreliable) or till auto. Sends ack (reliable blocking)
For large systems, unbuffered & non blocking primitives

4. Commn. Primitives Sync. primitives
– SEND primitive is blocked till corres. RECEIVE is executed at Rx. System – Rendezvous
Unblocking sync: copy msg to buffer at Tx.system.
Async. Primitives
No block, msg. are buffered
Comples: creating, managing & destroying buffers, msg. meant for processes that have already died.

5. RPC Issues with Msg.passing: Pairing request msg with responses.
Data repn. (diff. arch, languages etc.)
Knowing address of remotes m/c or server
Care for commn. & system failures
Programs – time dependent
Hides all these from programmer, PC extended for control and data access across nework
Interaction between Client and Server, Client that needs a service invokes procedure at Server

6. RPC
Basic operation:
On RPI, Calling process (Client) suspended, parameters passed to remote server , where procedure will be executed. On completion, results passed to Client and it resumes execution.
Design Issues:
Structure: ref. fig.4.5
Stub procedures can be generated at compile time or linked at run time.

7. RPC – Design Issues
Binding: process that determines remote procedure , m/c on which to be executed on RPI
Also checks for compatibility of parameters & procedure types
2 approaches : use of binding server – Servers register services they provide with BS, Client stub obtains address by querying BS
Client specifies m/c & service required, Server returns port number for commn.

8. RPC – Design Issues Parameter & result passing:
Stub procedure has to convert paramters, results to approp. Repn.
Std. format
Passing parameters by value – stub copies paramters in to msg.
By reference- complex , semantics of parameters in local & remote procedures can be different

9. RPC – Design Issues Error handling in DS - difficult
RPC can fail due to system or commn. Failure
Unwanted executions – orphans
Semantics (interpretations) :
Atleast once semantics
Exactly once semantics
Atmost once semantics
Correctness:

10. RPC – Design Issues Other Issues:
Low latency RPC, min. delay, datagram protocol, Ex: Future
High throughput RPC, bulk data transfer- TCP, Ex. Stream
RPI blocks calling process, limits concurrency, MultiRPC, PARPC
Incremental results cannot be returned to calling process while in progress
Protocol flexibility
Channel model- pipe for transmitting data and incremental results, channel groups for sequencing of calls