230 likes | 239 Views
Distributed Systems – Client Server Anatomy. Prof. Leonardo Mostarda University of Camerino. Last Lecture. Processes Threads Multithreaded clients Multithreaded servers Virtualisation. Outline. Client anatomy Server Anatomy Iterative and concurrent servers
E N D
Distributed Systems – Client Server Anatomy Prof. Leonardo Mostarda University of Camerino Prof. Leonardo Mostarda-- Camerino,
Last Lecture Processes Threads Multithreaded clients Multithreaded servers Virtualisation
Outline • Client anatomy • Server Anatomy • Iterative and concurrent servers • Stateful and stateless servers • Server cluster organisation • Distributed serverand IPv6
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
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
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,
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
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.
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
software for distribution transparency Masking communication failures with a server is typically done through client middleware.
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)
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?
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
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.
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
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?
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?
Server anatomy: server cluster organisation • Three tiers • a (logical) switch through which client requests are routed • servers dedicated to application processing • data-processing servers
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?
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
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
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.
Summary • Client anatomy • Server Anatomy • Iterative and concurrent servers • Stateful and stateless servers • Server cluster organisation • Distributed server and IPv6