1 / 33

Processes

Distributed Software Systems . 2. Software Architecture. Components/processes process = program in execution Often multi-threaded! How the processes are organized influences the overall application Connections between the components Systems architecture = instance of a software architecture. D

oya
Download Presentation

Processes

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

    1. Distributed Software Systems 1 Processes Ch. 1, 3 Tanenbaum Distributed Software Systems CS 707

    2. Distributed Software Systems 2 Software Architecture Components/processes process = program in execution Often multi-threaded! How the processes are organized influences the overall application Connections between the components Systems architecture = instance of a software architecture

    3. Distributed Software Systems 3 Multi-threading Implementation/use studied in 571 in the context of operating systems Advantages: Threads typically share the address space – thread context switching is inexpensive on a single processor. A multithreaded process can be executed on single processor or on multiprocessor transparently. Cooperating threads may be a natural structuring mechanism for some applications. Thread implementations exist that allow only the involved thread to block on a system call. Disadvantage: Controlling use of shared data left entirely to the programmer – This intellectual activity is studied in CS 706

    4. Distributed Software Systems 4 Issues in Client-Server Application Design Many choices arise in the design and implementation of client/server apps Application layering (two vs. three tier) Whether the client is multi-threaded Whether the server is multi-threaded

    5. Distributed Software Systems 5 Application Layering Figure 2-4. The simplified organization of an Internet search engine into three different layers.

    6. Distributed Software Systems 6 Application Layering (2) The simplest organization is to have only two types of machines: A client machine containing only the programs implementing (part of) the user-interface level A server machine containing the rest, the programs implementing the processing and data level

    7. Distributed Software Systems 7 Application Layering (3) Figure 2-5. Alternative client-server organizations (a)–(e).

    8. Distributed Software Systems 8 Application Layering (4) Figure 2-6. An example of a server acting as client.

    9. Distributed Software Systems 9 Issues in Client design Goal: Provide the means for users to interact with remove servers Multithreading hide communication latency allow multiple simultaneous connections Must know or find out the location of the server known endpoint (port) vs. a lookup mechanism Blocking (synchronous) request or non-blocking (asynchronous) Replication transparency

    10. Distributed Software Systems 10 Client-Side Software for Distribution Transparency Figure 3-10. Transparent replication of a server using a client-side solution.

    11. Distributed Software Systems 11 Issues in Server Design Providing endpoint information Known endpoint Daemon listening at endpoint superserver that spawns threads Connection-oriented or connection-less servers TCP or UDP? Concurrent or iterative servers: handle multiple requests concurrently or one after the other? Stateful or stateless servers

    12. Distributed Software Systems 12 Figure 3-11. (a) Client-to-server binding using a daemon.

    13. Distributed Software Systems 13 Figure 3-11. (b) Client-to-server binding using a superserver.

    14. Distributed Software Systems 14 Issues in Server Design Providing endpoint information Known endpoint Daemon listening at endpoint superserver that spawns threads Connection-oriented or connection-less servers TCP or UDP? Concurrent or iterative servers: handle multiple requests concurrently or one after the other? Stateful or stateless servers

    15. Distributed Software Systems 15 Connection-oriented servers Protocol used determines level of reliability Overhead of setup and tear down of connections TCP provides reliable-data delivery verifies that data arrives at other end, retransmits segments that don’t checks that data is not corrupted along the way makes sure data arrives in order eliminates duplicate packets provides flow control to make sure sender does not send data faster than receiver can consume it informs both client and server if underlying network becomes inoperable

    16. Distributed Software Systems 16 Connection-less servers UDP unreliable – best effort delivery UDP relies on application to take whatever actions are necessary for reliability UDP used if application protocol designed to handle reliability and delivery errors in an application-specific manner, e.g. audio and video on the internet overhead of TCP connections too much for application multicast

    17. Distributed Software Systems 17 Issues in Server Design Providing endpoint information Known endpoint Daemon listening at endpoint superserver that spawns threads Connection-oriented or connection-less servers TCP or UDP? Concurrent or iterative servers: handle multiple requests concurrently or one after the other? Stateful or stateless servers

    18. Distributed Software Systems 18 Stateful vs Stateless servers State ? Information that server maintains about the status of ongoing interactions with clients Stateful servers client state information maintained can help server in performing request faster state information needs to be preserved across (or reconstructed after) crashes Stateless servers information on clients not maintained and can change state without having to inform clients quicker and more reliable recovery after crashes smaller memory requirements Application protocol should have idempotent operations (operations that can be repeated multiple times without harm)

    19. Distributed Software Systems 19 Issues in Server Design Providing endpoint information Known endpoint Daemon listening at endpoint superserver that spawns threads Connection-oriented or connection-less servers TCP or UDP? Concurrent or iterative servers: handle multiple requests concurrently or one after the other? Stateful or stateless servers

    20. Distributed Software Systems 20 Concurrency in servers Concurrency needed if multiple clients and service is expensive Operating system support Multiple processes Threads Asynchronous I/O, e.g. using select() system call

    21. Distributed Software Systems 21 Multithreaded Servers (2) Figure 3-4. Three ways to construct a server.

    22. Distributed Software Systems 22 Multithreaded Servers (1) Figure 3-3. A multithreaded server organized in a dispatcher/worker model.

    23. Distributed Software Systems 23 Server Clusters Figure 3-12. The general organization of a three-tiered server cluster. Each tier may use specialized machines configured for the particular task.

    24. Distributed Software Systems 24 Server Clusters (2) Figure 3-13. The principle of TCP handoff.

    25. Distributed Software Systems 25 Distributed Servers Figure 3-14. Route optimization in a distributed server.

    26. Distributed Software Systems 26 Code Migration Process migration – an entire process is moved from one machine to another Code migration – move part of the processing Can be done client to server or server to client

    27. Distributed Software Systems 27 Motivation for Code Migration Load Sharing in Distributed Systems Long-running processes can be migrated to idle processors Client-server systems Code for data entry shipped to client system If large quantities of data need to be processed, it is better to ship the data processing component to the client Dynamically configurable client software More flexibility, Easier maintenance and upgrades of client software Enterprise and “Desktop Grids”, e.g. SETI@home Computationally-intensive tasks shipped to idle PCs around the network

    28. Distributed Software Systems 28 Migrating Code Figure 3-17. The principle of dynamically configuring a client to communicate to a server. The client first fetches the necessary software, and then invokes the server (performance, flexibility).

    29. Distributed Software Systems 29 Models for Code Migration A running process consists of Code segment Resource segment (references to files, devices, processes, …) Execution segment (private data, stack, program counter, registers, …) Weak mobility – only transfer code segment and initialization data Execution starts in known place Simple to implement Java applets Strong mobility – transfer code and execution segment More difficult to implement particularly in heterogenous environment One approach: runtime systems maintains a language-independent copy of the program stack More common approach: Use a virtual machine

    30. Distributed Software Systems 30 Models for Code Migration (2) Sender-initiated – machine that owns the code starts the migration Receiver-initiated – machine that will run the migrated code starts the process Java applets Security issues

    31. Distributed Software Systems 31 Figure 3-18. Alternatives for code migration.

    32. Distributed Software Systems 32 Migration and Local Resources Process-to-resource bindings make code migration difficult Three types of process to resource bindings Binding by identifier – when a process refers to a resource by its identifier, e.g. URL, IP address, local communication endpoint (socket) Binding by value – weaker form of binding when only the value of a resource is needed, e.g. when a program relies on standard language libraries Binding by type – weakest form of binding when a process indicates the type of a resource, e.g., a printer

    33. Distributed Software Systems 33 Migration and Local Resources (cont’d) When migrating code, we may need to change the references to resources but cannot change the kind of process-to-resource binding. How a resource reference is changed depends on the resource-to-machine bindings Unattached resources can be easily moved, e.g. data files associated only with the program being moved Fastened resources can be moved at a high cost, e.g. a database Fixed resources cannot be moved, e.g., local devices, local communication endpoint

More Related