1. 1 Distributed Systems: an Introduction G53ACC Chris Greenhalgh

2. 2 Contents l Distributed Systems and Parallel Architectures l Applications and Motivations l Client-Server Systems

3. 3 Distributed Systems l Def.: "A collection of autonomous computers linked by a computer network and equipped with distributed system software.”

4. 4 Parallel Computer Architectures A) SISD - “standalone” B) MIMD, shared memory - “parallel” C) MIMD, disjoint memory - “distributed”

5. 5 Disjoint vs. Shared memory: latencies l Network communication (to “access” remote memory) –~2 us custom cluster network (e.g MyriNet) –~ 1 ms Ethernet LAN, –10s ms WAN, 100s ms dialup/GPRS l Local memory access –~10 ns l ~100,000 times faster than Ethernet l 1,000,000+ times faster than WAN l CPU instruction time –~1 ns!

6. 6 Distributed System Programming Implications l Communication is relatively Slow l Requires different programming approaches l Communication is generally achieved by explicit actions rather than shared variables –Sending and receiving “messages” –“Distributed Shared Memory” is technically possible, but not common in use l Computation must be divided into relatively large communication-free chunks –Or most CPU time will be wasted waiting for messages

7. 7 Distributed System Applications l The Internet l Communication (e.g. electronic mail) l Network Information Retrieval (NIR) services (e.g. WWW) l Resource sharing, e.g. shared printers, shared disks l Collaborative applications (e.g. teleconferencing, networked games) l Supercomputers (implementation and access)

8. 8 Why build distributed systems (1)? Mirroring Reality l People are distributed –Support, –Collaboration l Information is distributed –Access, –Control, –Performance (mobile code) l Other resources are distributed –Physical devices (e.g. printer, robot)

9. 9 Why build distributed systems (2)? Performance / Cost l Centralised or distributed? –Law of diminishing returns on single CPU performance –The cost of moving ALL data to/from the centre across a wide-area may be prohibitive l So: distribute processing and communicate only as necessary –Sometimes necessary –Economic

10. 10 Challenge: Interconnection l Connecting independent components, requires use of common: –Paradigms and models? l i.e. ways of understanding, dividing up and organising distributed operations and activities –Formats –Protocols –Timing –Physical interfaces –Standards? (i.e. networking - see CCN!)

11. 11 One Common Paradigm: Client-Server Server (e.g. database) Application TCP/IP (e.g.) Application TCP/IP Application TCP/IP Clients

12. 12 Example: Resource Sharing l Resources include: –hardware components, e.g. disks and printers –software-defined entities e.g. files, databases, other data objects l But: –physically encapsulated within one computer –remote access requires communication l => Resource manager...

13. 13 Resource Sharing (cont.) l Resource manager = Software module = server –Manages a set of resources of a particular type –Implements management policies for: l naming, l Concurrency l E.g. –dept. print servers –disk servers (network drives)

14. 14 The Client-Server Model l = An effective general purpose approach to sharing information and resources: –Shared resources are held and managed by server processes. –Client processes issue requests to servers whenever they need to access one of their resources. –If the request is a valid one, the server performs the requested action and send a reply to the client process.

15. 15 Example: The X-Window system l A server controls access to the shared resource - the user's display and input(s). l Clients communicate with the server, and ask it to display information to the user (e.g. xterm, netscape,...) l So: –multiple clients can display information –conflicts are resolved by server (e.g. overlapping windows)

16. 16 Client-server Comments l Not the only approach to creating distributed systems –See also peer-to-peer, multi-tier, message- oriented l Often complicated by “callback” or “notification” features –Original “client” is sometimes the receiver of requests (callbacks or notifications) originated by the original “server” l But simple, common, powerful and manageable