Understanding Distributed Systems: Client-Server Anatomy

1. Distributed Systems – Client Server Anatomy Prof. Leonardo Mostarda University of Camerino Prof. Leonardo Mostarda-- Camerino,

2. Last Lecture Processes Threads Multithreaded clients Multithreaded servers Virtualisation

3. Outline • Client anatomy • Server Anatomy • Iterative and concurrent servers • Stateful and stateless servers • Server cluster organisation • Distributed serverand IPv6

4. Learning outcomes • Understand the client anatomy • Understand and discuss the server anatomy • Iterative and concurrent servers • Stateful and stateless servers • Understand and discuss the organisation of a cluster • Understand and discuss the use of IPv6 for implementing distributed server

5. Client anatomy:networked user interfaces • Clients are a way to interact with servers. • Interaction can take place in two ways • The client only provides direct access to the services by only offering the interface • Everything is done at the server (thin client) • For instance X windows

6. X Window System • X kernel contains all the terminal-specific device drivers, and as such, is generally highly hardware dependent. • X kernel and the X applications (Xlib) exchange events and data • Xlib can send a request to kill or create a window. • X kernel will react to local events such as keyboard and mouse input by sending event packets back to Xlib • A use of X window can be an application displaying to a window of another display system (ssh with the X forwarding argument ) Prof. Leonardo Mostarda-- Camerino,

7. Client anatomy:networked user interfaces • For each service the client has a separate component that contacts it • For instance an agenda running on a PDA that synchronises data • application-level protocol will handle the synchronization

8. software for distribution transparency • Client software comprises more than just user interfaces. • Part of the processing in a client-server application can be executed on the client side. • Examples are embedded client software such as ATMs , TV set-top boxes • In these cases, the user interface is a relatively small part of the client software, in contrast to the local processing and communication facilities.

9. software for distribution transparency • Beside interfaces and software, clients contain software for distribution transparency • Access transparency is usually implemented with a client stub that provides the same interface of the server, but hides differences (data, hardware, communication) • location, migration, and relocation is achieved through naming systems and cooperation with client software • For instance the server can inform the client of its change of location than rebinding can take place transparently on the client

10. software for distribution transparency Masking communication failures with a server is typically done through client middleware.

11. Server anatomy: General Design Issues • A server is a process implementing a specific service on behalf of a collection of clients. • There are several ways to organise servers. • ITERATIVE: the server itself handles the request and reply to the client. • CUNCURRENT: server does not handle the request itself, but passes it to a separate thread/process, after which it waits for the next request. • Concurrent server are implemented with threads or processes (Unix fork)

12. Server anatomy: General Design Issues • Globally assigned ,e.g., FTP on port 21, Web Server on port 80 • There are many services that do not require a preassigned end point. In this case we can use a daemon. • Clients contact a server on a port • How do clients know the end point (port) of a service?

13. Server anatomy: General Design Issues • Servers continuously waiting for connections may be a waste of resources especially when they are not heavily loaded • It is often more efficient to have a single superserver listening to each port associated with a specific service • The superverserver will launch the appropriate server • Inetd of Unix is an example

14. Server anatomy: General Design Issues • exit the client application and restart (the server will tear down the old connection) • A better approach could be to implement a client that can send out-of-band data (high priority data) • server listen to a separate control end point for out-of-band data • The same connection is used for out-of-band data • How do we interrupt a server working? For instance I am using ftp and I am uploading the wrong file.

15. Server anatomy: General Design Issues • Choosing between a stateful or stateless server is a very important design issue • “A stateless server does not keep information on the state of its clients, and can change its own state without having to inform any client” • For instance a Web server is stateless. It records some info but if this information is lost, it will not lead to a disruption of the service • “A stateful server generally maintains persistent information on its clients.” • A file server must maintain a table with files and permissions

16. Server anatomy: General Design Issues • the server design is simple because there is no need to dynamically allocate storage. • If a client dies in mid-transaction there is not need to clean the state of the server. • Disadvantages of Stateless servers? • It may be necessary to include additional information in every request that needs to be parsed by the server (ex. Cookies) Advantages of Stateless servers?

17. Server anatomy: General Design Issues • Performance improvement over stateless servers is often an important benefit of stateful designs • Disadvantages of Stateless servers? • In general, a stateful server needs to recover its entire state as it was just before the crash. Advantages of Stateful servers?

18. Server anatomy: server cluster organisation • Three tiers • a (logical) switch through which client requests are routed • servers dedicated to application processing • data-processing servers

19. Server anatomy: server cluster organisation • Let us take a closer look at the first tier (remember clients need to access in a transparent way) • A switch forms the entry point for the server cluster, offering a single network address • PROBLEMS! • A switch has got a static address • It is a single point of failure • A DNS can return multiple addresses of replicated switches but they are still statically assigned • SOLUTION?

20. Distributed Servers • “a distributed server is a possibly dynamically changing set of machines, with also possibly varying access points which appears as a single powerful machine.” • In order to implement it we can make use of mobility support for IP version 6 (MIPv6). • A Mobile node (MN) has a home network wit a stable home address (HoA). This home network has a special router attached, known as the home agent • When a MN attaches to a foreign network it will receive a care-of address (CoA) • A CN that wishes to communicate with MN will use the HoA then the home agent will forward to the current CoA • A single unique address can be assigned to the distributed Server • A new server will register with its CoA at Different times

21. Distributed Servers • Home agent and Care of Address are a centrilised point • Rout optimisation is the solution the CoA is forwarded by the Home Agent

22. Server anatomy: server cluster organisation • A server cluster should appear to the outside world as a single computer • However, when it comes to managing a cluster, the situation changes dramatically. • We can connect to the servers in order to monitor, install, and change components • We can use a centralised management console in order to collect info from various servers • Centralised management is not feasible when the cluster has got hundreds of nodes. • As it turns out, support for very large server clusters is almost always ad hoc.

23. Summary • Client anatomy • Server Anatomy • Iterative and concurrent servers • Stateful and stateless servers • Server cluster organisation • Distributed server and IPv6