Docsity
Docsity

Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity


Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan


Guidelines and tips
Guidelines and tips

Understanding Distributed Communication in CSE 120: RPCs and Network File Systems - Prof. , Study notes of Computer Science

A lecture note from cse 120, principles of operating systems, fall 2004, focusing on remote procedure calls (rpc) and network file systems (nfs). Rpc is a common means for remote communication used both by operating systems and applications, and nfs is an implementation of a file system using rpc. The client-server paradigm, messages, procedure calls, rpc stubs, and the nfs protocol, as well as the challenges of transparency, statelessness, and consistency in distributed systems.

Typology: Study notes

2009/2010

Uploaded on 03/28/2010

koofers-user-6z9
koofers-user-6z9 🇺🇸

10 documents

1 / 11

Toggle sidebar

Related documents


Partial preview of the text

Download Understanding Distributed Communication in CSE 120: RPCs and Network File Systems - Prof. and more Study notes Computer Science in PDF only on Docsity! 1 CSE 120 Principles of Operating Systems Fall 2004 Lecture 14: Remote Procedure Call And Network File System Geoffrey M. Voelker November 22, 2004 CSE 120 – Lecture 14 – Remote Procedure Call 2 © 2004 Geoffrey M. Voelker Why is RPC Interesting? Remote Procedure Call (RPC) is the most common means for remote communication It is used both by operating systems and applications NFS is implemented as a set of RPCs DCOM, CORBA, Java RMI, etc., are all basically just RPC Someday (soon?) you will most likely have to write an application that uses remote communication (or you already have) You will most likely use some form of RPC for that remote communication So it’s good to know how all this RPC stuff works » More “debunking the magic” 2 November 22, 2004 CSE 120 – Lecture 14 – Remote Procedure Call 3 © 2004 Geoffrey M. Voelker Clients and Servers The prevalent model for structuring distributed computation is the client/server paradigm A server is a program (or collection of programs) that provide a service (file server, name service, etc.) The server may exist on one or more nodes Often the node is called the server, too, which is confusing A client is a program that uses the service A client first binds to the server (locates it and establishes a connection to it) A client then sends requests, with data, to perform actions, and the servers sends responses, also with data November 22, 2004 CSE 120 – Lecture 14 – Remote Procedure Call 4 © 2004 Geoffrey M. Voelker Messages Initially with network programming, people hand-coded messages to send requests and responses Hand-coding messages gets tiresome Need to worry about message formats Have to pack and unpack data from messages Servers have to decode and dispatch messages to handlers Messages are often asynchronous Messages are not a very natural programming model Could encapsulate messaging into a library Just invoke library routines to send a message Which leads us to RPC… 5 November 22, 2004 CSE 120 – Lecture 14 – Remote Procedure Call 9 © 2004 Geoffrey M. Voelker RPC Example Server Interface: int Add(int x, int y); Client Program: … sum = server->Add(3,4); … Server Program: int Add(int x, int, y) { return x + y; } If the server were just a library, then Add would just be a procedure call November 22, 2004 CSE 120 – Lecture 14 – Remote Procedure Call 10 © 2004 Geoffrey M. Voelker RPC Example: Call Client Program: sum = server->Add(3,4); Server Program: int Add(int x, int, y) {} Client Stub: Int Add(int x, int y) { Alloc message buffer; Mark as “Add” call; Store x, y into buffer; Send message; } RPC Runtime: Send message to server; Server Stub: Add_Stub(Message) { Remove x, y from buffer r = Add(x, y); } RPC Runtime: Receive message; Dispatch, call Add_Stub; 6 November 22, 2004 CSE 120 – Lecture 14 – Remote Procedure Call 11 © 2004 Geoffrey M. Voelker RPC Example: Return Client Program: sum = server->Add(3,4); Server Program: int Add(int x, int, y) {} Client Stub: Int Add(int x, int y) { Create, send message; Remove r from reply; return r; } RPC Runtime: Return reply to stub; Server Stub: Add_Stub(Message) { Remove x, y from buffer r = Add(x, y); Store r in buffer; } RPC Runtime: Send reply to client; November 22, 2004 CSE 120 – Lecture 14 – Remote Procedure Call 12 © 2004 Geoffrey M. Voelker RPC Marshalling Marshalling is the packing of procedure parameters into a message packet The RPC stubs call type-specific procedures to marshal (or unmarshal) the parameters to a call The client stub marshals the parameters into a message The server stub unmarshals parameters from the message and uses them to call the server procedure On return The server stub marshals the return parameters The client stub unmarshals return parameters and returns them to the client program 7 November 22, 2004 CSE 120 – Lecture 14 – Remote Procedure Call 13 © 2004 Geoffrey M. Voelker RPC Binding Binding is the process of connecting the client to the server The server, when it starts up, exports its interface Identifies itself to a network name server Tells RPC runtime its alive and ready to accept calls The client, before issuing any calls, imports the server RPC runtime uses the name server to find the location of a server and establish a connection The import and export operations are explicit in the server and client programs Breakdown of transparency November 22, 2004 CSE 120 – Lecture 14 – Remote Procedure Call 14 © 2004 Geoffrey M. Voelker RPC Transparency One goal of RPC is to be as transparent as possible Make remote procedure calls look like local procedure calls We have seen that binding breaks transparency What else? Failures – remote nodes/networks can fail in more ways than with local procedure calls » Need extra support to handle failures well Performance – remote communication is inherently slower than local communication » If program is performance-sensitive, could be a problem 10 November 22, 2004 CSE 120 – Lecture 14 – Remote Procedure Call 19 © 2004 Geoffrey M. Voelker Consistency Since NFS is stateless, consistency is tough NFS can be (mostly) consistent, but limits performance NFS assumes that if you want consistency, applications will use higher-level mechanisms to guarantee it Writes are supposed to be atomic But performed in multiple RPCs (larger than a network packet) Simultaneous writes from clients can interleave RPCs (bad) Server caching Can cache reads, but we saw that it cannot cache writes November 22, 2004 CSE 120 – Lecture 14 – Remote Procedure Call 20 © 2004 Geoffrey M. Voelker Consistency (2) Client caching can lead to consistency problems Caching a write on client A will not be seen by other clients Cached writes by clients A and B are unordered at server Since sharing is rare, though, NFS clients usually do cache NFS statelessness is both its key to success and its Achilles’ heel NFS is straightforward to implement and reason about But limitations on caching can severely limit performance » Dozens of network file system designs and implementations that perform much better than NFS But note that it is still the most widely used remote file system protocol and implementation 11 November 22, 2004 CSE 120 – Lecture 14 – Remote Procedure Call 21 © 2004 Geoffrey M. Voelker RPC Summary RPC is the most common model for communication in distributed applications “Cloaked” as DCOM, CORBA, Java RMI, etc. Also used on same node between applications RPC is essentially language support for distributed programming What else have we seen use language support? RPC relies upon a stub compiler to automatically generate client/server stubs from the IDL server descriptions These stubs do the marshalling/unmarshalling, message sending/receiving/replying NFS uses RPC to implement remote file systems November 22, 2004 CSE 120 – Lecture 14 – Remote Procedure Call 22 © 2004 Geoffrey M. Voelker Next Time Tue 11/30: Research talk Thu 12/02: Final review
Docsity logo



Copyright © 2024 Ladybird Srl - Via Leonardo da Vinci 16, 10126, Torino, Italy - VAT 10816460017 - All rights reserved