mc714 sistemas distribuidos
play

MC714 - Sistemas Distribuidos slides by Maarten van Steen (adapted - PowerPoint PPT Presentation

MC714 - Sistemas Distribuidos slides by Maarten van Steen (adapted from Distributed System - 3rd Edition) Chapter 04: Communication Version: March 28, 2019 Communication: Foundations Layered Protocols Basic networking model Application


  1. MC714 - Sistemas Distribuidos slides by Maarten van Steen (adapted from Distributed System - 3rd Edition) Chapter 04: Communication Version: March 28, 2019

  2. Communication: Foundations 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 Violates access transparency The OSI reference model 2 / 37

  3. Communication: Foundations Layered Protocols Low-level layers Recap Physical layer: contains the specification and implementation of bits, and their transmission between sender and receiver Data link layer: prescribes the transmission of a series 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. The OSI reference model 3 / 37

  4. Communication: Foundations 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 communication The OSI reference model 4 / 37

  5. Communication: Foundations Layered Protocols Middleware layer Observation Middleware is invented to provide common services and protocols that can be used by many different applications A rich set of communication protocols (Un)marshaling of data, necessary for integrated systems Naming protocols, to allow easy sharing of resources Security protocols for secure communication Scaling mechanisms, such as for replication and caching Middleware protocols 5 / 37

  6. Communication: Foundations Layered Protocols An adapted layering scheme Application protocol Application Middleware protocol Middleware Host-to-host protocol Operating system Physical/Link-level protocol Hardware Network Middleware protocols 6 / 37

  7. Communication: Foundations Types of Communication Types of communication Distinguish... Synchronize at� Synchronize at � Synchronize after� request submission request delivery processing by server Client Request � Transmission� interrupt Storage� facility Reply Server Time Transient versus persistent communication Asynchronous versus synchronous communication 7 / 37

  8. Communication: Foundations Types of Communication Types of communication Transient versus persistent Synchronize at� Synchronize at � Synchronize after� request submission request delivery processing by server Client Request � Transmission� interrupt Storage� facility Reply Server Time Transient communication: Comm. server discards message when 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. 8 / 37

  9. Communication: Foundations Types of Communication Types of communication Places for synchronization Synchronize at� Synchronize at � Synchronize after� request submission request delivery processing by server Client Request � Transmission� interrupt Storage� facility Reply Server Time At request submission At request delivery After request processing 9 / 37

  10. Communication: Foundations Types of Communication Client/Server Some observations Client/Server computing is generally based on a model of transient synchronous communication: Client and server have to be active at time of communication Client issues request and blocks until it receives reply Server essentially waits only for incoming requests, and subsequently processes them 10 / 37

  11. Communication: Foundations Types of Communication Client/Server Some observations Client/Server computing is generally based on a model of transient synchronous communication: Client and server have to be active at 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 handled immediately: the client is waiting The model may simply not be appropriate (mail, news) 10 / 37

  12. Communication: Foundations Types of Communication 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 11 / 37

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

  14. Communication: Remote procedure call Basic RPC operation Basic RPC operation Client machine Server machine Server process Client process 1. Client call to Implementation 6. Stub makes procedure of doit local call to “doit” Server stub r = doit( a,b ) r = doit( a,b ) Client stub proc: “doit” proc: “doit” 5. Stub unpacks type1: val(a) type1: val(a) 2. Stub builds message type2: val(b) type2: val(b) message proc: “doit” 4. Server OS Client OS Server OS type1: val(a) hands message type2: val(b) to server stub 3. Message is sent across the network 1 Client procedure calls client stub. 6 Server does local call; returns result to stub. Stub builds message; calls local OS. 2 Stub builds message; calls OS. 7 3 OS sends message to remote OS. 8 OS sends message to client’s OS. Remote OS gives message to stub. 4 9 Client’s OS gives message to stub. 5 Stub unpacks parameters; calls 10 Client stub unpacks result; returns to client. server. 13 / 37

  15. Communication: Remote procedure call Parameter passing RPC: Parameter passing There’s more than just wrapping 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 encoding: How are basic data values represented (integers, floats, characters) How are complex data values represented (arrays, unions) Conclusion Client and server need to properly interpret messages, transforming them into machine-dependent representations. 14 / 37

  16. Communication: Remote procedure call Parameter passing RPC: Parameter passing Some assumptions Copy in/copy out semantics: while procedure is executed, nothing can be assumed about parameter values. All data that is to be operated on is passed by parameters. Excludes passing references to (global) data. 15 / 37

  17. Communication: Remote procedure call Parameter passing RPC: Parameter passing Some assumptions Copy in/copy out semantics: while procedure is executed, nothing can be assumed about parameter values. All data that is to be operated on is passed by parameters. Excludes passing references to (global) data. Conclusion Full access transparency cannot be realized. 15 / 37

  18. Communication: Remote procedure call Parameter passing RPC: Parameter passing Some assumptions Copy in/copy out semantics: while procedure is executed, nothing can be assumed about parameter values. All data that is to be operated on is passed by parameters. Excludes passing references to (global) data. Conclusion Full access transparency cannot be realized. A remote reference mechanism enhances access transparency Remote reference offers unified access to remote data Remote references can be passed as parameter in RPCs Note: stubs can sometimes be used as such references 15 / 37

  19. Communication: Remote procedure call Variations on RPC Asynchronous RPCs Essence Try to get rid of the strict request-reply behavior, but let the client continue without waiting for an answer from the server. Wait for Callback to client Client acceptance Return Call remote procedure from call Return results Accept Request request Server Call local procedure Time Asynchronous RPC 16 / 37

  20. Communication: Remote procedure call Variations on RPC Sending out multiple RPCs Essence Sending an RPC request to a group of servers. Server Call local procedure Callbacks to client Client Call remote procedures Server Call local procedure Time Multicast RPC 17 / 37

  21. Communication: Remote procedure call Example: DCE RPC RPC in practice 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 Writing a Client and a Server 18 / 37

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend