CS514: Intermediate Course in Operating Systems

1. CS514: Intermediate Course in Operating Systems Professor Ken Birman Ben Atkin: TA Lecture 6: Sept. 12

2. Client-Server Computing • 99% of all distributed systems use client-server architectures! • Today: look at the client-server problem • Discuss stateless and stateful architectures • Review major file system and database system issues (will revisit some issues in later lectures)

3. DCE, COM and RMI • Examples of “distributed computing environments.” • They provide tools for performing RPC in client-server systems, standards for data marshalling, etc. • Include services for authentication, binding, life-cycle management, clock synchronization • Won’t focus on specifics today: look at the big picture

4. Client-Server concept • Server program is shared by many clients • RPC protocol typically used to issue requests • Server may manage special data, run on an especially fast platform, or have an especially large disk • Client systems handle “front-end” processing and interaction with the human user

5. Server and its clients

6. Examples of servers • Network file server • Database server • Network information server • Domain name service • Microsoft Exchange • Kerberos authentication server

7. Business examples • Risk manager for a bank: tracks exposures in various currencies or risk in investments • Theoretical price for securities or bonds: traders use this to decide what to buy and what to sell • Server for an ATM: decides if your withdrawal will be authorized

8. Bond pricing example • Server receives market trading information, currency data, interest rates data • Has a database of all the bonds on the market • Client expresses interest in a given bond, or in finding a bond with certain properties • Server calculates what that bond (or what each bond) should cost given current conditions

9. Why use a client-server approach? • Pricing parameters are “expensive” (in terms of computing resources) to obtain: must monitor many data sources and precompute many time-value of money projections for each bond • Computing demands may be extreme: demands a very high performance machine • Database of bonds is huge: large storage, more precomputation

10. On client side • Need a lot of CPU and graphics power to display the data and interact with the user • Dedicated computation provides snappy response time and powerful decision making aids • Can “cache” or “save” results of old computations so that if user revisits them, won’t need to reissue identical request to server

11. Summary of typical split • Server deals with bulk data storage, high perf. computation, collecting huge amounts of background data that may be useful to any of several clients • Client deals with the “attractive” display, quick interaction times • Use of caching to speed response time

12. Statefulness issues • Client-server system is stateless if: Client is independently responsible for its actions, server doesn’t track set of clients or ensure that cached data stays up to date • Client-server system is stateful if: Server tracks its clients, takes actions to keep their cached states “current”. Client can trust its cached data.

13. Best known examples? • The UNIX NFS file system is stateless. Bill Joy: “Once they replaced my file server during the evening while my machine was idle. The next day I resumed work right where I had left off, and didn’t even notice the change!” • Database systems are usually stateful: Client reads database of available seats on plane, information stays valid during transaction

14. Typical issues in design • Client is generally simpler than server: may be single-threaded, can wait for reply to RPC’s • Server is generally multithreaded, designed to achieve extremely high concurrency and throughput. Much harder to develop • Reliability issue: if server goes down, all its clients may be “stuck”. Usually addressed with some form of backup or replication.

15. Use of caching • In stateless architectures, cache is responsibility of the client. Client decides to remember results of queries and reuse them. Example: caching Web proxies, the NFS client-side cache. • In stateful architectures, cache is owned by server. Server uses “callbacks” to its clients to inform them if cached data changes, becomes invalid. Cache is “shared state” between them.

16. Butler Lampson’s advice • Cache “hints” • Speed up system when hint is correct • Some mechanism can detect when hint is wrong and seek more up to date information • If cached data is viewed as hints, relationship of client and server can be stateless • Example: information about location of a mailbox: if hint is wrong, can run more costly protocol

17. Butler Lampson’s advice Application Name Server Cache Object was moved Hint became stale

18. Example of stateless approach • NFS is stateless: clients obtain “vnodes” when opening files; server hands out vnodes but treats each operation as a separate event • NFS trusts: vnode information, user’s claimed machine id, user’s claim uid • Client uses write-through caching policy

19. ... example issues raised • Cache may be stale if someone writes the file after it is opened • Create operation may fail with error EEXISTS if server is not responsive at instant when the create is issued

20. Example of stateful approach • Transactional software structure: • Data manager holds database • Transaction manager does begin op1 op2 ... opn commit • Transaction can also abort; abort is default on failure • Transaction on database system: • Atomic: all or nothing effects • Concurrent: can run many transactions at same time • Independent: concurrent transactions don’t interfere • Durable: once committed, results are persistent

21. Comments on transactions • Well matched to database applications • Requires special programming style • Typically, spits operations into read and update categories. Transactional architecture can distinguish these • Idea is to run transactions concurrently but to make it look as if they ran one by one in some sequential (serial) order

22. Why are transactions stateful? • Client knows what updates it has done, what locks it holds. Database knows this too • Client and database share the guarantees of the model. See consistent states • Approach is free of the inconsistencies and potential errors observed in NFS

23. Stateful file servers? • Several file servers use aspects of transactional approach: • Andrew file system caches whole files, server knows who has a copy • Sprite file system caches 4k records, uses sophisticated cache consistency protocols • Quicksilver adopts aspects of transactional model to ensure that either all of a set of operations occur, or none

24. Looking ahead • Later in course will study transactional model in detail; right now will leave topic open • Notice its “database assumptions” • Separation of computation from data • Operations are split into reads and writes • Transactions are designed to run independently • Can be applied in object oriented systems but proves awkward for very general distibuted uses

25. Client-server performance issues • Performance revolves around degree of concurrency achieved in server, effectiveness of caching, quality of prefetching • NFS “versus” AFS, Sprite illustrates this point

26. NFS performance: from prefetching • User opens file, reads sequentially • Each read done as a separate RPC from server, but... • If reads are sequential, client starts to prefetch blocks by anticipating the read and pre-issuing the RPC • Result: data is usually in cache when needed

27. AFS, Sprite do large block xfers • User opens file • Server sends a large amount of data, or whole file, using a streaming protocol • Approach reduces server workload: n requests from client become one request, file is sent very efficiently • But client must cache much more data

28. Experience? • NFS, AFS and Sprite behave comparably for “random” requests • AFS and Sprite do much better under heavy load • RPC approach consumes much more CPU time and network time

29. NFS security problems • NFS supports an authentication protocol but rarely used: can’t be exported and is available mostly for SUN systems • Lacking authentication, server can be fooled by applications that construct fake packets! • Implication is that almost any user of a network can access any NFS file stored on that network without real permissions being enforced!!!

30. Current issues in client-server systems • Research is largely at a halt: we know how to build these systems • Challenges are in the applications themselves, or in the design of the client’s and servers for a specific setting • Biggest single problem is that client systems know the nature of the application, but servers have all the data

31. Typical debate topic? • Ship code to the data (e.g. program from client to server)? • ... or ship data to the code? (e.g. client fetches the data needed) • Will see that Java, Tacoma and Telescript offer ways of trading off to avoid inefficient use of channels and maximum flexibility

32. Message Oriented Middleware • Emerging extension to client-server architectures • Concept is to weaken the link between the client and server but to preserve most aspects of the “model” • Client sees an asynchronous interface: request is sent independent of reply. Reply must be dequeued from a reply queue later

33. MOMS: How they work • MOM system implements a queue in between clients and servers • Each sends to other by enqueuing messages on the queue or queues for this type of request/reply • Queues can have names, for “subject” of the queue • Client and server don’t need to be running at the same time.

34. MOMS: How they work client MOMS Client places message into a “queue” without waiting for a reply. MOMS is the “server”

35. MOMS: How they work server MOMS Server removes message from the queue and processes it.

36. MOMS: How they work server MOMS Server places any response in a “reply” queue for eventual delivery to the client. May have a timeout attached (“delete after xxx seconds”)

37. MOMS: How they work client MOMS Client retrieves response and resumes its computation.

38. Pros and Cons of MOMS • Decoupling of sender, destination is a plus: can design the server and client without each knowing much about the other, can extend easily • Performance is poor, a (big) minus: overhead of passing through an intermediary • Priority, scheduling, recoverability are pluses .... use this approach if you can afford the performance hit, a factor of 10-100 compared to RPC

39. Other MOMS issues? • Management of the queues • Handling runaway applications that flood queue with requests or fail to collect responses • Cleanup after a crash in applications not designed to handle this case

40. Major uses of MOMS • IBM MQ Server used heavily to connect older mainframe applications to new distributed computing front-ends • DEC Message Q popular in process-control and production settings that mix midsize computers with dedicated machine tools • Will see “message bus” examples of MOMS later in this lecture series

41. Client-Server Issues • A big challenge is to make servers scale • Add more and more clients • Or somehow clone the server • Or perhaps partition data so that different requests can go to different servers with the corresponding subset of the data • Management of server clusters is a very hard problem • Fault-tolerance is also a hot topic

42. Scaling • A farmof servers is a physically distributed large-scale pool of machines with the same service available at lots of places • Farms usually are built to exploit physical proximity • Example: Exodus and Akamai are companies that operate server farms for their clients

43. Akamai Looks like a server with unusual capacity

44. Akamai server Main page still comes from server But “static content” fetched from a close-byAkamai server running at your ISP

45. RACS and RAPS • RACS: Reliable array of cloned servers • Servers are identical • Just spray requests for even load • RAPS: Reliable array of partitioned servers • Servers partition data: A-F, G-Z… • A partition might be a RACS • Typically, if needed, use some form of backup for fault-tolerance

46. Akamai Main page still comes from server The server itself is a cluster But “static content” fetched from a close-byAkamai server running at your ISP

47. Akamai Main page still comes from server The server itself is a cluster Backups provide fault-tolerance But “static content” fetched from a close-byAkamai server running at your ISP

48. Fault-Tolerance • We showed one backup per node • In real settings might prefer one per n nodes • A complex topic that will be covered later in the course • Challenge is to replicate the data needed so the backup can seamlessly take over when the primary fails • Also need a good way to detect failure!

49. Next lecture? • Will study issues associated with consistency • Reading: Chapters 9, 10 • Homework: identify as many examples of client-server structures as possible in your local area networking environment. • Hint: look for examples of X.500 “servers”, SNMP “servers”, file servers, time servers, database servers, authentication servers...