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

Last Lecture zProcesses zThreads zMultithreaded clients zMultithreaded servers zVirtualisation

Outline zClient anatomy zServer Anatomy yIterative and concurrent servers yStateful and stateless servers zServer cluster organisation zDistributed server and IPv6

Learning outcomes zUnderstand the client anatomy zUnderstand and discuss the server anatomy yIterative and concurrent servers yStateful and stateless servers zUnderstand and discuss the organisation of a cluster zUnderstand and discuss the use of IPv6 for implementing distributed server

zClients are a way to interact with servers. zInteraction can take place in two ways zThe client only provides direct access to the services by only offering the interface xEverything is done at the server (thin client) zFor instance X windows Client anatomy:networked user interfaces

X Window System zX kernel contains all the terminal-specific device drivers, and as such, is generally highly hardware dependent. zX kernel and the X applications (Xlib) exchange events and data yXlib can send a request to kill or create a window. yX kernel will react to local events such as keyboard and mouse input by sending event packets back to Xlib zA 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, 6

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

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

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

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

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

zClients contact a server on a port zHow do clients know the end point (port) of a service? 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.

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

zHow do we interrupt a server working? For instance I am using ftp and I am uploading the wrong file. 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

zChoosing between a stateful or stateless server is a very important design issue z“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” yFor 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 z“A stateful server generally maintains persistent information on its clients.” yA file server must maintain a table with files and permissions Server anatomy: General Design Issues

zAdvantages of Stateless servers? 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)

zAdvantages of Stateful servers? 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.

zThree tiers ya (logical) switch through which client requests are routed yservers dedicated to application processing ydata-processing servers Server anatomy: server cluster organisation

zLet us take a closer look at the first tier (remember clients need to access in a transparent way) zA switch forms the entry point for the server cluster, offering a single network address Server anatomy: server cluster organisation 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?

Distributed Servers z“a distributed server is a possibly dynamically changing set of machines, with also possibly varying access points which appears as a single powerful machine.” zIn order to implement it we can make use of mobility support for IP version 6 (MIPv6). yA 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 yWhen a MN attaches to a foreign network it will receive a care-of address (CoA) yA CN that wishes to communicate with MN will use the HoA then the home agent will forward to the current CoA zA single unique address can be assigned to the distributed Server zA new server will register with its CoA at Different times

Distributed Servers zHome agent and Care of Address are a centrilised point zRout optimisation is the solution the CoA is forwarded by the Home Agent

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

Summary zClient anatomy zServer Anatomy yIterative and concurrent servers  Stateful and stateless servers zServer cluster organisation zDistributed server and IPv6