1, Processes
Ch. 3 Tanenbaum Distributed Software Systems CS 707
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
Distributed Software Systems 2
Distributed Software Systems
1
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.
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
Disadvantage: Controlling use of shared data left entirely to the programmer This intellectual activity is studied in CS 706
Distributed Software Systems 3 Distributed Software Systems 4
1
Application Layering
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
Figure 2-4. The simplified organization of an Internet search engine into three different layers.
Distributed Software Systems 5 Distributed Software Systems 6
Application Layering (3)
Application Layering (4)
Figure 2-5. Alternative client-server organizations (a) (e).
thin client
Distributed Software Systems 7
Figure 2-6. An example of a server acting as client.
Distributed Software Systems 8
2
Issues in Client design
Goal: Provide the means for users to interact with remove servers Multithreading
hide communication latency allow multiple simultaneous connections
Client-Side Software for Distribution Transparency
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
Distributed Software Systems 9
Figure 3-10. Transparent replication of a server using a client-side solution.
Distributed Software Systems 10
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
Distributed Software Systems 11
Figure 3-11. (a) Client-to-server binding using a daemon.
Distributed Software Systems 12
3
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?
Figure 3-11. (b) Client-to-server binding using a superserver.
Distributed Software Systems 13
Concurrent or iterative servers: handle multiple requests concurrently or one after the other? Stateful or stateless servers
Distributed Software Systems 14
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 dont 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
Distributed Software Systems 15
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
Distributed Software Systems 16
4
Issues in Server Design
Providing endpoint information
Known endpoint Daemon listening at endpoint superserver that spawns threads
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
Connection-oriented connection-less or servers
TCP or UDP?
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)
Distributed Software Systems 18
Concurrent or iterative servers: handle multiple requests concurrently or one after the other? Stateful or stateless servers
Distributed Software Systems 17
Issues in Server Design
Providing endpoint information
Known endpoint Daemon listening at endpoint superserver that spawns threads
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
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
Distributed Software Systems 19 Distributed Software Systems 20
5
Multithreaded Servers (2)
Figure 3-4. Three ways to construct a server.
Multithreaded Servers (1)
Figure
3-3. A multithreaded server organized in a dispatcher/worker model.
Distributed Software Systems 22
Distributed Software Systems
21
Server Clusters
Server Clusters (2)
Figure 3-12. The general organization of a three-tiered server cluster. Each tier may use specialized machines configured for the particular task.
Distributed Software Systems 23
Figure 3-13. The principle of TCP handoff.
Distributed Software Systems 24
6
Distributed Servers
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
Figure 3-14. Route optimization in a distributed server.
Distributed Software Systems 25 Distributed Software Systems 26
Motivation for Code Migration
Load Sharing in Distributed Systems
Long-running processes can be migrated to idle processors
Migrating Code
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
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).
27 Distributed Software Systems 28
Distributed Software Systems
7
Models for Code Migration
A running process consists of
Code segment Resource segment (references to...