Distributed Systems Principles and Paradigms Chapter 04 (version - PDF document

Distributed Systems Principles and Paradigms Chapter 04 (version February 18, 2008 ) Maarten van Steen Vrije Universiteit Amsterdam, Faculty of Science Dept. Mathematics and Computer Science Room R4.20. Tel: (020) 598 7784 E-mail:steen@cs.vu.nl, URL: www.cs.vu.nl/ ∼ steen/ 01 Introduction 02 Architectures 03 Processes 04 Communication 05 Naming 06 Synchronization 07 Consistency and Replication 08 Fault Tolerance 09 Security 10 Distributed Object-Based Systems 11 Distributed File Systems 12 Distributed Web-Based Systems 13 Distributed Coordination-Based Systems 00 – 1 /

Layered Protocols • Low-level layers • Transport layer • Application layer • Middleware layer 04 – 1 Communication/4.1 Layered Protocols

Basic Networking Model Application protocol Application 7 Presentation protocol Presentation 6 Session protocol Session 5 Transport protocol Transport 4 Network protocol 3 Network Data link protocol 2 Data link Physical protocol 1 Physical Network Drawbacks: • Focus on message-passing only • Often unneeded or unwanted functionality • Question: Violates transparency? 04 – 2 Communication/4.1 Layered Protocols

Low-level layers Physical layer: contains the specification and imple- mentation of bits, and their transmission between sender and receiver Data link layer: prescribes the transmission of a se- ries of bits into a frame to allow for error and flow control Network layer: describes how packets in a network of computers are to be routed . Observation: for many distributed systems, the lowest- level interface is that of the network layer. 04 – 3 Communication/4.1 Layered Protocols

Transport Layer Important: The transport layer provides the actual communication facilities for most distributed systems. Standard Internet protocols: • TCP: connection-oriented, reliable, stream-oriented communication • UDP: unreliable (best-effort) datagram communi- cation Note: IP multicasting is generally considered a stan- dard available service. 04 – 4 Communication/4.1 Layered Protocols

Middleware Layer Observation: Middleware is invented to provide com- mon services and protocols that can be used by many different applications: • A rich set of communication protocols , but which allow different applications to communicate • (Un)marshaling of data, necessary for integrated systems • Naming protocols , so that different applications can easily share resources • Security protocols , to allow different applications to communicate in a secure way • Scaling mechanisms , such as support for repli- cation and caching Note: what remains are truly application-specific protocols Question: Such as...? 04 – 5 Communication/4.1 Layered Protocols

Types of Communication (1/3) Synchronize at� Synchronize at � Synchronize after� request submission request delivery processing by server Client Request � Transmission� interrupt Storage� facility Reply Server Time Distinguish: • Transient versus persistent communication • Asynchrounous versus synchronous commu- nication 04 – 6 Communication/4.1 Layered Protocols

Types of Communication (2/3) Synchronize at� Synchronize at � Synchronize after� request submission request delivery processing by server Client Request � Transmission� interrupt Storage� facility Reply Server Time Transient communication: A message is discarded by a communication server as soon as it cannot be delivered at the next server, or at the receiver. Persistent communication: A message is stored at a communication server as long as it takes to deliver it at the receiver. 04 – 7 Communication/4.1 Layered Protocols

Types of Communication (3/3) Synchronize at� Synchronize at � Synchronize after� request submission request delivery processing by server Client Request � Transmission� interrupt Storage� facility Reply Server Time Places for synchronization: • At request submission • At request delivery • After request processing 04 – 8 Communication/4.1 Layered Protocols

Client/Server Some observations: Client/Server computing is gen- erally based on a model of transient synchronous communication : • Client and server have to be active at the time of communication • Client issues request and blocks until it receives reply • Server essentially waits only for incoming requests, and subsequently processes them Drawbacks synchronous communication: • Client cannot do any other work while waiting for reply • Failures have to be dealt with immediately (the client is waiting) • In many cases the model is simply not appropri- ate (mail, news) 04 – 9 Communication/4.1 Layered Protocols

Messaging Message-oriented middleware: Aims at high-level persistent asynchronous communication : • Processes send each other messages, which are queued • Sender need not wait for immediate reply, but can do other things • Middleware often ensures fault tolerance 04 – 10 Communication/4.1 Layered Protocols

Remote Procedure Call (RPC) • Basic RPC operation • Parameter passing • Variations 04 – 11 Communication/4.2 Remote Procedure Call

Basic RPC Operation (1/2) Observations: • Application developers are familiar with simple pro- cedure model • Well-engineered procedures operate in isolation (black box) • There is no fundamental reason not to execute procedures on separate machine Conclusion: communication between caller & callee can be hidden by using procedure-call mechanism. Wait for result Client Call remote Return procedure from call Request Reply Server Call local procedure Time and return results 04 – 12 Communication/4.2 Remote Procedure Call

Basic RPC Operation (2/2) Server machine Client machine Server process Client process 1. Client call to Implementation 6. Stub makes procedure of add local call to "add" Server stub k = add(i,j) k = add(i,j) Client stub proc: "add" proc: "add" 5. Stub unpacks int: val(i) int: val(i) 2. Stub builds message int: val(j) int: val(j) message proc: "add" 4. Server OS Server OS Client OS int: val(i) hands message int: val(j) to server stub 3. Message is sent across the network 1. Client procedure calls client stub as usual. 2. Client stub builds message and calls local OS. 3. Client’s OS sends message to remote OS. 4. Remote OS gives message to server stub. 5. Server stub unpacks parameters and calls server. 6. Server does work and returns result to the stub. 7. Server stub packs it in message and calls OS. 8. Server’s OS sends message to client’s OS. 9. Client’s OS gives message to client stub. 10. Client stub unpacks result and returns to the client. 04 – 13 Communication/4.2 Remote Procedure Call

RPC: Parameter Passing (1/2) Parameter marshaling: There’s more than just wrap- ping parameters into a message: • Client and server machines may have different data representations (think of byte ordering) • Wrapping a parameter means transforming a value into a sequence of bytes • Client and server have to agree on the same en- coding: – How are basic data values represented (inte- gers, floats, characters) – How are complex data values represented (ar- rays, unions) • Client and server need to properly interpret mes- sages, transforming them into machine-dependent representations. 04 – 14 Communication/4.2 Remote Procedure Call

RPC: Parameter Passing (2/2) RPC parameter passing: • RPC assumes copy in/copy out semantics: while procedure is executed, nothing can be as- sumed about parameter values (only Ada sup- ports this model). • RPC assumes all data that is to be operated on is passed by parameters. Excludes passing references to (global) data . Conclusion: full access transparency cannot be re- alized. Observation: If we introduce a remote reference mech- anism, access transparency can be enhanced: • Remote reference offers unified access to remote data • Remote references can be passed as parameter in RPCs 04 – 15 Communication/4.2 Remote Procedure Call

Asynchronous RPCs Essence: Try to get rid of the strict request-reply be- havior, but let the client continue without waiting for an answer from the server. Wait for result Client Wait for acceptance Client Call remote Call remote Return Return procedure procedure from call from call Request Accept request Request Reply Server Time Server Call local procedure Time Call local procedure and return results (a) (b) Variation: deferred synchronous RPC : Interrupt client Wait for acceptance Client Return Call remote from call Return procedure Acknowledge results Accept Request request Server Time Call local procedure Call client with one-way RPC 04 – 16 Communication/4.2 Remote Procedure Call

RPC in Practice Essence: Let the developer concentrate on only the client- and server-specific code; let the RPC system (generators and libraries) do the rest. Uuidgen Interface definition file IDL compiler Client code Client stub Header Server stub Server code #include #include C compiler C compiler C compiler C compiler Client stub Server stub Server Client object file object file object file object file Runtime Runtime Linker Linker library library Client Server binary binary 04 – 17 Communication/4.2 Remote Procedure Call