1. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 DISTRIBUTED SYSTEMS Principles and Paradigms Second Edition ANDREW S. TANENBAUM MAARTEN VAN STEEN Chapter 3 Processes

2. Outline 3.1 Threads 3.2 Virtualization 3.3 Clients 3.4 Servers 3.5 Code Migration 3.6 Summary Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5

3. Process communications Multithreads Client, server Virtualization (independent and complete environments, regardless of the underlying hardware and OS platforms) high degree of protability Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5

4. Multithreaded Servers (1) Figure 3-3. A multithreaded server organized in a dispatcher/worker model.

5. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 The Role of Virtualization in Distributed Systems Figure 3-5. (a) General organization between a program, interface, and system. (b) General organization of virtualizing system A on top of system B.

6. 3.4 Servers Server architectures Multithreaded Multiple servers running simultaneously on the same machine. Listen socket public port number Working socket for each client request e.g, inetd in UNIX for well known Internet services (HTTP, FTP, etc, etc) Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5

8. Client/server socket interaction: TCP wait for incoming connection request connectionSocket = serverSocket.accept() create socket, port= x, for incoming request: serverSocket = socket() create socket, connect to hostid, port= x clientSocket = socket() server (running on hostid ) client send request using clientSocket read request from connectionSocket write reply to connectionSocket TCP connection setup close connectionSocket read reply from clientSocket close clientSocket

9. 1. FTP client contacts FTP server at port 21, specifying TCP as transport protocol; Client obtains authorization over control connection; Client browses remote directory by sending commands over control connection. 2. When server receives a command for a file transfer, the server opens a second TCP data connection to client; After transferring one file, server closes data connection. Server opens another TCP data connection to transfer another file. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Server architectures Multithreaded out-of-band data FTP client FTP server TCP control connection port 21 TCP data connection port 20

10. States at servers Stateless vs stateful (soft state) Stateless: No disruption to services Stateful can provide performance optimization; Recover from crach is hard; Web server: stateless (cookie is not server side feature) Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Server architectures

11. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Server Clusters (1) Figure 3-12. The general organization of a three-tiered server cluster. Server architectures

12. Server clusters Two tiered (server with database) The multimedia server case Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Server architectures

13. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Figure 3-13. The principle of TCP handoff. Access Transparency Single portal handle TCP connections (requests) TCP handoff for internal load balance

14. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Distributed servers e.g., DNS Stable access Ease case: a high performance, stable server (of server cluster) Hard case: achieving stable access via mobile IP Server architectures

15. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Distributed Servers Figure 3-14. Route optimization in a distributed server. Achieving stable access via mobile IP

16. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Managing Server Clusters Example: PlanetLab http://www.planet-lab.org/ PlanetLab is a global research network that supports the development of new network services. since 2003, developed new technologies for distributed storage, network mapping, peer-to-peer systems, distributed hash tables, and query processing. Slice: a collection of distributed resources for a specific application PlanetLab can concurrently support many experiments of different distributed systems and applications

17. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 a PlanetLab node Figure 3-15. The basic organization of a PlanetLab node. VMM: Separation Isolation Slice: a set of d vservers, each on a different node A node can concurrently support many slices (experiments)

18. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 PlanetLab (1) PlanetLab management issues: Nodes belong to different organizations. –Each organization should be allowed to specify who is allowed to run applications on their nodes, –And restrict resource usage appropriately. Monitoring tools available assume a very specific combination of hardware and software. –All tailored to be used within a single organization. Programs from different slices but running on the same node should not interfere with each other.

19. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 PlanetLab (2) Figure 3-16. The management relationships between various PlanetLab entities. At a node: Node manager (vserver) Resource specification (Rspec) Use via a service provider (account) Slice creation/management via a slice authority Monitor a collection of nodes

20. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 PlanetLab (3) Relationships between PlanetLab entities: A node owner puts its node under the regime of a management authority, possibly restricting usage where appropriate. A management authority provides the necessary software to add a node to PlanetLab. A service provider registers itself with a management authority, trusting it to provide well-behaving nodes.

21. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 PlanetLab (4) Relationships between PlanetLab entities: A service provider contacts a slice authority to create a slice on a collection of nodes. The slice authority needs to authenticate the service provider. Via out of band control for credentials A node owner provides a slice creation service for a slice authority to create slices. It essentially delegates resource management to the slice authority. A management authority delegates the creation of slices to a slice authority.

22. More on supporting the development of new network services (distributed systems) Virtualization and federation Example of PlanetLab Example of EmuLab Example of ProtoGENI Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5