1. Kyung Hee University 1/41 Introduction Chapter 1

2. Kyung Hee University 2/41 Agenda -Definition -Hardware concept -Software concept -The Client-Server model

3. Kyung Hee University 3/41 Definition of a Distributed System (1) A distributed system is: A collection of independent computers that appears to its users as a single coherent system.

4. Kyung Hee University 4/41 Definition of a Distributed System (2) A distributed system organized as middleware. Note that the middleware layer extends over multiple machines. 1.1

5. Kyung Hee University 5/41 Goal of Distributed system Connecting users to resources Openness Transparency Scalability

6. Kyung Hee University 6/41 Transparency in a Distributed System Different forms of transparency in a distributed system. TransparencyDescription Access Hide differences in data representation and how a resource is accessed LocationHide where a resource is located MigrationHide that a resource may move to another location Relocation Hide that a resource may be moved to another location while in use Replication Hide that a resource is replicated Concurrency Hide that a resource may be shared by several competitive users FailureHide the failure and recovery of a resource Persistence Hide whether a (software) resource is in memory or on disk

7. Kyung Hee University 7/41 Scalability Problems Examples of scalability limitations. ConceptExample Centralized servicesA single server for all users Centralized dataA single on-line telephone book Centralized algorithmsDoing routing based on complete information

8. Kyung Hee University 8/41 Scaling Techniques (1) 1.4 The difference between letting: a)a server or b)a client check forms as they are being filled

9. Kyung Hee University 9/41 Scaling Techniques (2) 1.5 An example of dividing the DNS name space into zones.

10. Kyung Hee University 10/41 Hardware Concepts 1.6 Different basic organizations and memories in distributed computer systems

11. Kyung Hee University 11/41 Multiprocessors (1) A bus-based multiprocessor. 1.7

12. Kyung Hee University 12/41 Multiprocessors (2) a)A crossbar switch b)An omega switching network 1.8

13. Kyung Hee University 13/41 Multicomputers Each node is an autonomous machine  Private memory Lower traffic than multiprocessors  CPU – CPU versus CPU – Memory traffic Homogeneous or Heterogeneous

14. Kyung Hee University 14/41 Similar nodes  Same processors and memory space Homogeneous access to network  Single network Bus-based or point-to-point communication Homogeneous Multicomputer Systems (1)

15. Kyung Hee University 15/41 Homogeneous Multicomputer Systems (2) a)Grid b)Hypercube 1-9

16. Kyung Hee University 16/41 Heterogeneous Multicomputers Different nodes  Nodes can be complex system None-homogeneous access to network  Different network Distributed systems are commonly built on this H/W category  Need S/W to make it transparent

17. Kyung Hee University 17/41 Software Concepts An overview between DOS (Distributed Operating Systems) NOS (Network Operating Systems) Middleware SystemDescriptionMain Goal DOS Tightly-coupled operating system for multi- processors and homogeneous multicomputers Hide and manage hardware resources NOS Loosely-coupled operating system for heterogeneous multicomputers (LAN and WAN) Offer local services to remote clients Middleware Additional layer atop of NOS implementing general-purpose services Provide distribution transparency

18. Kyung Hee University 18/41 Uniprocessor Operating Systems Separating applications from operating system code through a microkernel. 1.11

19. Kyung Hee University 19/41 Multicomputer Operating Systems (1) General structure of a multicomputer operating system 1.14

20. Kyung Hee University 20/41 Multicomputer Operating Systems (2) Alternatives for blocking and buffering in message passing. 1.15

21. Kyung Hee University 21/41 Distributed Shared Memory Systems (1) a)Pages of address space distributed among four machines b)Situation after CPU 1 references page 10 c)Situation if page 10 is read only and replication is used

22. Kyung Hee University 22/41 Distributed Shared Memory Systems (2) False sharing of a page between two independent processes. 1.18

23. Kyung Hee University 23/41 Network Operating System (1) General structure of a network operating system. 1-19

24. Kyung Hee University 24/41 Network Operating System (2) Two clients and a server in a network operating system. 1-20

25. Kyung Hee University 25/41 Network Operating System (3) Different clients may mount the servers in different places. 1.21

26. Kyung Hee University 26/41 DOS and NOS v.s DS DOS qualifies as DS?  Computers are not independent  Easy to use and transparent NOS qualifies as DS?  No single coherent view  Scalable and open

27. Kyung Hee University 27/41 Positioning Middleware General structure of a distributed system as middleware. 1-22

28. Kyung Hee University 28/41 Middleware and Openness In an open middleware-based distributed system, the protocols used by each middleware layer should be the same, as well as the interfaces they offer to applications. 1.23

29. Kyung Hee University 29/41 Comparison between Systems A comparison between multiprocessor operating systems, multicomputer operating systems, network operating systems, and middleware based distributed systems. Item Distributed OS Network OS Middleware- based OS Multiproc.Multicomp. Degree of transparencyVery HighHighLowHigh Same OS on all nodesYes No Number of copies of OS1NNN Basis for communication Shared memory MessagesFilesModel specific Resource management Global, central Global, distributed Per node ScalabilityNoModeratelyYesVaries OpennessClosed Open

30. Kyung Hee University 30/41 The Clients and Servers Model

31. Kyung Hee University 31/41 Client and Server -Clients request services. -Servers provide services by replying to the requests. General interaction between a client and a server.

32. Kyung Hee University 32/41 An Example Client and Server (1) The header.h file used by the client and server. Client and server need to agree on a couple things first!

33. Kyung Hee University 33/41 An Example Client and Server (2) A sample server (A basic server loop) -The server continually listens for new requests (receive). -Extracting the request and simply executes it. -It then prepares a response message and sends it back to the requesting client.

34. Kyung Hee University 34/41 An Example Client and Server (3) Sample Client: using the server to copy a file. 1-27 b

35. Kyung Hee University 35/41 Application Layering A client-server application typically consists of three layers: 1.User-Interface level: +Consists of the programs that allow end users to interact with application. 2.Processing level: +Implements the application logic (core functionality) +Typically implemented at the server side 3.Data level +Maintain the actual data on which the application operate. +Also keep data consistent across different application

36. Kyung Hee University 36/41 Application Layering The general organization of an Internet search engine into three different layers 1-28 Web browser Application server Database server

37. Kyung Hee University 37/41 Client-Server Architectures Alternative client-server organizations (a) – (e). 1-29 Two-tiers Architectures

38. Kyung Hee University 38/41 Client-Server Architectures (con.t) An example of a server acting as a client. 1-30 Three-tiers Architectures

39. Kyung Hee University 39/41 Modern Architectures An example of horizontal distribution of a Web service. -Vertical distribution Model : where the tiers corresponded directly with the logical organization of the apps (The previous architectures) -H orizontal distribution Model: where the application layers are physically split up into logically equivalent part -> This is how high-performance web services (e.g., Google, Amazon, E-bay..)

40. Kyung Hee University 40/41 End of Chapter 1

41. Kyung Hee University 41/63 Communication Chapter 2

42. Kyung Hee University 42/63 Agenda 1-Layered protocols 2-Remote Procedure 3-Remote Object Invocation 4-Message-Oriented Communication 5-Stream-Oriented Communication

43. Kyung Hee University 43/63 1 - Layered Protocols

44. Kyung Hee University 44/63 OSI Model Layers, interfaces, and protocols in the OSI model. -OSI: Open Systems Interconnection -Developed by the International Organization for Standardization (ISO) -P rovides a generic framework to discuss the layers and functionalities of communication protocols.

45. Kyung Hee University 45/63 OSI Model (con.t) A typical message as it appears on the network. 2-2

46. Kyung Hee University 46/63 OSI Protocol Layers -Physical layer +Deals with the transmission of bits +Physical interface between data transmission device (e.g. computer) and transmission medium or network Concerned with: Characteristics of transmission medium, Signal levels, Data rates -Data link layer: +Deals with detecting and correcting bit transmission errors +Bits are group into frames +Checksums are used for integrity

47. Kyung Hee University 47/63 OSI Protocol Layers (con.t) Discussion between a receiver and a sender in the data link layer.

48. Kyung Hee University 48/63 OSI Protocol Layers (con.t) -Network layer: +Performs multi-hop routing across multiple networks +Implemented in end systems and routers -Transport layer: +Packing of data +Reliable delivery of data (breaks message into pieces small enough, assign each one a sequence number and then send them) +Ordering of delivery Examples: TCP (connection-oriented) UDP (connectionless) RTP (Real-time Transport Protocol)

49. Kyung Hee University 49/63 OSI Protocol Layers (con.t) (a) Normal operation of TCP. (b) Transactional TCP. Client-Server TCP protocol

50. Kyung Hee University 50/63 OSI Protocol Layers (con.t) -Session layer +Provide dialog control to keep track of which party is talking and it provides synchronization facilities -Presentation layer +Deals with non-uniform data representation and with compression and encryption -Application layer +Support for user applications e.g. HTTP, SMPT, FTP

51. Kyung Hee University 51/63 Middleware Protocols An adapted reference model for networked communication. -Support high-level communication services -The session and presentation layers are merged into the middleware layer, Ex: Microsoft ODBC (Open Database Connectivity), OLE DB…

52. Kyung Hee University 52/63 2 - Remote Procedure Call

53. Kyung Hee University 53/63 Remote Procedure call -Basic idea: To execute a procedure at a remote site and ship the results back. - Goal: To make this operation as distribution transparent as possible (i.e., the remote procedure call should look like a local one to the calling procedure). Example: read(fd, buf, nbytes)

54. Kyung Hee University 54/63 Client and Server Stubs count = doSomething(); procedure doSomething(); OS Client StubServer Stub Client Server Definition: Are additional functions which are added to the main functions in order to support for RPC

55. Kyung Hee University 55/63 Steps of a Remote Procedure Call 1.Client procedure calls client stub in normal way 2.Client stub builds message, 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, calls server 6.Server does work, returns result to the stub 7.Server stub packs it in message, calls local OS 8.Server's OS sends message to client's OS 9.Client's OS gives message to client stub 10.Stub unpacks result, returns to client

56. Kyung Hee University 56/63 Passing Value Parameters (1) Steps involved in doing remote computation through RPC 2-8

57. Kyung Hee University 57/63 Passing Value Parameters (2) a)Original message on the Pentium (little-endian) b)The message after receipt on the SPARC (big-endian ) c)The message after being inverted. The little numbers in boxes indicate the address of each byte In a large distributed system, multiple machine types are present Each machine has its own representation for number, characters, and others data items.

58. Kyung Hee University 58/63 Parameter Specification - Caller and callee agree on the format of message they exchange Ex: word = 4 bytes float = 1 word character is the rightmost byte of word => the client stub must use this format and the server stub know that incoming message for foobar has this format

59. Kyung Hee University 59/63 Asynchronous RPC (1) a)The interconnection between client and server in a traditional RPC b)The interaction using asynchronous RPC 2-12 -Avoids blocking of the client process. -A llows the client to proceed without getting the final result of the call.

60. Kyung Hee University 60/63 Deferred Synchronous RPC(2) A client and server interacting through two asynchronous RPCs 2-13 One-way RPC model: client does not wait for an acknowledgement of the server’s acceptance of the request.

61. Kyung Hee University 61/63 Example DCE RPC -What is DCE ? (Distributed Computing Environment) DCE is a true middleware system in that it is designed to execute as a layer of abstraction between exiting (network) operating system and distributed application. -Goals of DCE RPC Makes it possible for client to access a remote service by simply calling a local procedure. -Components: +Languages +Libraries +Daemon +Utility programs +Others

62. Kyung Hee University 62/63 Writing a Client and a Server The steps in writing a client and a server in DCE RPC. 2-14 Generate a prototype IDL file containing an interface identify Filling in the names of remote procedure and their parameters IDL compiler is call to compile into three files

63. Kyung Hee University 63/63 Binding a Client to a Server Client-to-server binding in DCE. 2-15 Endpoint (port) is used by server’s OS to distinguish incoming message

64. Kyung Hee University 64/63 3-Remote Object Invocation

65. Kyung Hee University 65/63 Objects separate their actual implementation from their interface Distributed Objects (1) Distributed object = an object which publishes its interface on other machines Remote object = a distributed object whose state is centralized

66. Kyung Hee University 66/63 Distributed Objects (2) Common organization of a remote object with client-side proxy. 2-16

67. Kyung Hee University 67/63 Binding a Client to an Object (1) When a client binds to a distributed object, an implementation of the object interface (proxy) is loaded into the client’s address space

68. Kyung Hee University 68/63 Binding a Client to an Object (2) a)An example with implicit binding using only global references b)An example with explicit binding using global and local references Problems:+ Language dependent + Address of server an Object reference Distr_object* obj_ref;//Declare a systemwide object reference obj_ref = …;// Initialize the reference to a distributed object obj_ref-> do_something();// Implicitly bind and invoke a method (a) Distr_object objPref;//Declare a systemwide object reference Local_object* obj_ptr;//Declare a pointer to local objects obj_ref = …;//Initialize the reference to a distributed object obj_ptr = bind(obj_ref);//Explicitly bind and obtain a pointer to the local proxy obj_ptr -> do_something();//Invoke a method on the local proxy (b)

69. Kyung Hee University 69/63 Parameter Passing (2) Pass remote object by reference Pass local object by value Local object = an object in the client’s address space

70. Kyung Hee University 70/63 Parameter Passing (2) The situation when passing an object by reference or by value. 2-18 stream

71. Kyung Hee University 71/63 Example: Java RMI (1) Java Distributed-Object Model Distributed objects integrated into the Language Goal is to achieve transparency! (keep as much of semantics of nondistributed objects as possible)

72. Kyung Hee University 72/63 Java RMI (2) Local vs. Remote object differences when 1.Cloning: Cloning the actual object only, and not its proxies 2.Synchronizing Synchronized methods Only proxy synchronization is allowed only

73. Kyung Hee University 73/63 Java RMI (3)  Any serializable object type can be a parameter to an RMI Platform dependent objects (e.g., sockets, file descriptors,etc) are not serializable  Local objects are passed by value, remote objects are passed by reference  Proxy can be used as a reference to a remote object: Possible to serialize the proxy and send it to another server

74. Kyung Hee University 74/63 Java RMI (4) stream

75. Kyung Hee University 75/63 4-Message-Oriented Communication

76. Kyung Hee University 76/63 Persistence and Synchronicity in Communication General organization of a communication system in which hosts are connected through a network +Each host is connected to a single communication server. +Hosts and communication servers can have buffers.

77. Kyung Hee University 77/63 Persistent communication of letters back in the days of the Pony Express Persistence and Synchronicity in Communication

78. Kyung Hee University 78/63 Definition -Persistent vs. Transient  Persistent messages are stored as long as necessary by the communication system (e.g., e-mail)  Transient messages are discarded when they cannot be delivered (e.g., TCP/IP) -Synchronous vs. Asynchronous  Asynchronous implies sender proceeds as soon as it sends the message no blocking  Synchronous implies sender blocks till the receiving host buffers the message Persistence and Synchronicity in Communication

79. Kyung Hee University 79/63 (a) Persistent asynchronous communication (b) Persistent synchronous communication Persistence and Synchronicity in Communication

80. Kyung Hee University 80/63 (c) Transient asynchronous communication (d) Receipt-based transient synchronous communication Persistence and Synchronicity in Communication

81. Kyung Hee University 81/63 (e) Delivery-based transient synchronous communication at message delivery (f) Response-based transient synchronous communication Persistence and Synchronicity in Communication

82. Kyung Hee University 82/63 Socket primitives for TCP/IP PrimitiveMeaning SocketCreate a new communication endpoint BindAttach a local address to a socket ListenAnnounce willingness to accept connections AcceptBlock caller until a connection request arrives ConnectActively attempt to establish a connection SendSend some data over the connection ReceiveReceive some data over the connection CloseRelease the connection  Berkeley Sockets:  Socket: a communication endpoint to which an application can write data (be sent to network) and read incoming data. Message-Orient Transient Communication

83. Kyung Hee University 83/63 Connection-oriented communication pattern using sockets  Berkeley Sockets: Create a new endpoint Associate endpoint Reserve buffer Block waiting for reqs Automatic binding after connection Message-Orient Transient Communication

84. Kyung Hee University 84/63 qSockets ware deemed insufficient because: qSupport only send and receive primitives qDesigned for communication using general-purpose protocol stacks such as TCP/IP q->The Message-Passing Interface (MPI) qDesigned for multiprocessor machines and high-performance parallel programming qProvides a high-level of abstraction than sockets qSupport diverse forms of buffering and synchronization (over 100 functions) Message-Orient Transient Communication

85. Kyung Hee University 85/63  The Message-Passing Interface (MPI) PrimitiveMeaning MPI_bsendAppend outgoing message to a local send buffer MPI_sendSend a message and wait until copied to local or remote buffer MPI_ssendSend a message and wait until receipt starts MPI_sendrecvSend a message and wait for reply MPI_isendPass reference to outgoing message, and continue MPI_issendPass reference to outgoing message, and wait until receipt starts MPI_recvReceive a message; block if there are none MPI_irecvCheck if there is an incoming message, but do not block Some of the most intuitive message-passing primitives of MPI. Message-Orient Transient Communication

86. Kyung Hee University 86/63  Message-Queue Model  Apps communicate by in serting messages in spe cific queues  Loosely-couple com munication  Support for:  Persistent asynchronous c ommunication  Longer message tra nsfers (e.g., e-mail systems) Four combinations for loosely-coupled communications using queues. Message-Orient Persistent Communication

87. Kyung Hee University 87/63  General Architecture of a Message-Queuing System  Messages can only be put and received from local queues.  The message-queuing system is responsible for transmitting the messages between the source queues and destination queues, meanwhile storing the messages as long as necessary.  Each queue is maintained by a queue manager. Example The relationship between queue-level addressing and network-level addressing. Message-Orient Persistent Communication

88. Kyung Hee University 88/63  General Architecture of a Message-Queuing System  Queue managers are not only responsible for directly interacting wit h applications but are also responsible for acting as relays (or r outers). Queue managers form an overlay network, acting as routers Message-Orient Persistent Communication

89. Kyung Hee University 89/63  General – purpose of a Message-Queuing System  Enable persistent communication between processes  Handling access to database  Perform computation  … In wide range of application, include: -Email -Workflow -Groupware -Batch processing Message-Orient Persistent Communication

90. Kyung Hee University 90/63  Message Brokers The general organization of a message broker in a message-queuing system Message-Orient Persistent Communication end

91. Kyung Hee University 91/63 5-Stream-Oriented Communication

92. Kyung Hee University 92/63

93. Kyung Hee University 93/63 * Relationship between substreams are also timedependent

94. Kyung Hee University 94/63 Data Stream (1) Setting up a stream between two processes across a network. Setting up a stream directly between two devices.

95. Kyung Hee University 95/63 Data Stream (2) An example of multicasting a stream to several receivers.

96. Kyung Hee University 96/63 Client Traffic Shaping

97. Kyung Hee University 97/63 Specifying QoS (1) A flow specification. Question: who specifies the flow? Characteristics of the InputService Required maximum data unit size (bytes) Token bucket rate (bytes/sec) Toke bucket size (bytes) Maximum transmission rate (bytes/sec) Loss sensitivity (bytes) Loss interval (  sec) Burst loss sensitivity (data units) Minimum delay noticed (  sec) Maximum delay variation (  sec) Quality of guarantee

98. Kyung Hee University 98/63 Specifying QoS (2) The principle of a token bucket algorithm.

99. Kyung Hee University 99/63 Resource ReSerVation Protocol (RSVP) A transport-level control protocol Used to provide QoS for continuous data streams by reserving resources {Bandwidth, buffers, and processing capacity} Issue: how to translate QoS parameters to resource usage? 2 ways to translate RSVP translates QoS parameters into data link layer parameters Data link layer provides its own set of parameters (as in ATM)

100. Kyung Hee University 100/63 Setting Up a Stream (1) The basic organization of RSVP for resource reservation in a distributed system.

101. Kyung Hee University 101/63 Setting Up a Stream (2)

102. Kyung Hee University 102/63 Setting Up a Stream (3)

103. Kyung Hee University 103/63 Setting Up a Stream (4)

104. Kyung Hee University 104/63

105. Kyung Hee University 105/63 Synchronization Mechanisms (1) The principle of explicit synchronization on the level data units.

106. Kyung Hee University 106/63 Synchronization Mechanisms (2) The principle of synchronization as supported by high-level interfaces. 2-41 message

107. Kyung Hee University 107/63 END OF CHAPTER 2