Slide 1From Local to Network File SystemSlide 3Process Coordination Two fundamental approachesProcess Coordination Shared Memory v. Message PassingMessage Passing Naming communicantsWeb requests conform to what model?Message Passing Issues Synchronization semanticsSemantics of Message Passing send(receiver, message)Semantics of Message Passing receive(sender, message)Which do you think would be easier to program?RPC is not message passingRemote Procedure CallRPC: Message Passing EvolvesSlide 15RPC (Cont’d.)Problems with RPCJava RMI (remote method invocation) is an example of an RPC system.Network and Distributed File SystemsNaming IssuesPerformance Issues: Simple CaseWhy does turning every file system operation into an RPC to a server perform poorly?Sun’s Network File System (NFS)NFS Protocol: StatelessnessNFS Protocol: ConsistencyNFS: SummaryAndrew File System (AFS): A Case Study1Network and DistributedFile SystemsWith content fromDistributed Communication SystemsChristophe Bisciglia, Aaron Kimball, & Sierra Michels-Slettvet2From Local to Network File SystemSo far, we have assumed that files are stored on local disk …How can we generalize the design to access files stored on a remote server?Need to invoke file creation and management methods on the remote serverBasic mechanisms: Message passing primitivesRemote Procedure Calls (RPC)3A network file system is likely to be better than a local file system in what respects?A. Read/write performanceB. AvailabilityC. Fault toleranceD. Ease of management4Communication and synchronization based on...Shared memoryAssume processes/threads can read & write a set of shared memory locationsInter-process communication isimplicit, synchronization is explicitProcess CoordinationTwo fundamental approachesthreadthreadthreadthreadExecution StackExecution StackProgram CodeProgram CodeDataDataExecution StackExecution Stackreceive(message )processprocessprocessprocesssend(message)Message passingInter-process communication is explicit, synchronization is implicit5Process CoordinationShared Memory v. Message PassingShared memoryEfficient, familiarDifficult to provide across machine boundaries. send(int id, String message);receive(int id, String message); send(int id, String message);receive(int id, String message);Canonical syntax:process foobegin : x := 1 :end fooprocess barbegin : while(x==0) ; :end barglobal int x = 0;Message passingExtensible to communication in distributed systems6Message PassingNaming communicantsHow do processes refer to each other?Does a sender explicitly name a receiver?Can a receiver receive froma group? (a reduction operation)“Mailbox”“Mailbox”SSR1R1R2R2RmRm...“Port”“Port”RRS1S1S2S2SnSn...SSRRCan a message be sent to a group?7Web requests conform to what model?1. Many-to-one2. One-to-one3. One-to-many8Message Passing IssuesSynchronization semanticsWhen does a send/receive operation terminate?OS KernelSender ReceiverOS KernelSender ReceiverPartially blocking/non-blocking:send()/receive() with timeoutNon-blocking: Send operation “immediately” returnsReceive operation returns if no message is availableBlocking:Sender waits until its message is receivedReceiver waits if no message is available9Semantics of Message Passingsend(receiver, message)Send message to receiverWait until message is accepted.Broadcast message to all receivers. Wait until message is accepted by allSend message to receiverBroadcast message to all receiversBlocking Non-blockingExplicit(single)Implicit(group)SynchronizationNaming10Semantics of Message Passingreceive(sender, message)Wait for a message from senderWait for a message from any senderIf there is a message from sender then receive it, else continueIf there is a message from any sender then receive it, else continueBlocking Non-blockingExplicit(single)Implicit(group)SynchronizationNaming11Which do you think would be easier to program?A. A message passing program that blocks.B. A message passing program that does not block.12RPC is not message passingRegular client-server protocols involve sending data back and forth according to shared stateClient: Server:HTTP/1.0 index.html GET 200 OK Length: 2400 (file data)HTTP/1.0 hello.gif GET 200 OK Length: 81494 …13Remote Procedure CallRPC servers will call arbitrary functions in dll, exe, with arguments passed over the network, and return values back over networkClient: Server:foo.dll,bar(4, 10, “hello”) “returned_string”foo.dll,baz(42) err: no such function …14RPC: Message Passing EvolvesRemote procedure calls abstract out the send/await-reply paradigm into a “procedure call”Remote procedure calls can be made to look like “local” procedure calls by using a stub that hides the details of remote communicationOSKernel“Client” “Server”StubStubFileServerFileServerApplicationApplicationStubStub15Remote Procedure Callprocess P1begin : call Function(args) :end P1process P1begin : call Function(args) :end P1procedure realFunction(args)begin : : return(results)end realFunctionprocedure realFunction(args)begin : : return(results)end realFunctionClient ServerNetworkprocedure Function(args)begin <marshall parameters> send(FunctionServer,params) receive(FunctionServer,results) <unpack results> return(results)end Functionprocedure Function(args)begin <marshall parameters> send(FunctionServer,params) receive(FunctionServer,results) <unpack results> return(results)end Functionprocess FunctionServerbegin loop sender := select() receive(sender,params) <unpack parameters> call realFunction(args) <marshall results> send(sender,results) end loopend FunctionServerprocess FunctionServerbegin loop sender := select() receive(sender,params) <unpack parameters> call realFunction(args) <marshall results> send(sender,results) end loopend FunctionServer16RPC (Cont’d.)Similarities between procedure call and RPCParameters  request messageResult  reply messageName of procedure  passed in request messageReturn address  mailbox of the clientImplementation issues:Stub generationCan be automatedRequires the signature of the