ken@cs.cornell.edu (Ken Birman) (06/17/91)
In light of Dalia's last posting, I thought readers might be interested in a re-posting of this, from our comp.sys.isis archives. Don also sent some material on his course, which we can make available upon request. - Relay-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site cornell.UUCP - Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site cornell.UUCP - Path: cornell!ken - From: ken@gvax.cs.cornell.edu (Ken Birman) - Newsgroups: comp.sys.isis - Subject: User feedback: an ISIS-based graduate course - Message-ID: <42351@cornell.UUCP> - Date: 18 Jun 90 20:41:08 GMT - Date-Received: 18 Jun 90 20:41:08 GMT - Sender: nobody@cornell.UUCP - Reply-To: ken@cs.cornell.edu (Ken Birman) - Distribution: comp - Organization: Cornell Univ. CS Dept, Ithaca NY - Lines: 238 - I have had many inquiries about using ISIS in graduate courses, - so when Don Smith sent me the email included below, I asked if he - minded my posting it. - We would be very interested in learning of other experiences with ISIS - in courses. - By the way, I didn't end up using it in my own course this semester: - the beta-testing of ISIS V2.0 didn't seem like something my students - should have to endure. - --- begin included message --- - Date: Sat, 26 May 90 13:19:25 -0400 - From: Don Smith <smithfd@cs.unc.edu> - To: ken@cs.cornell.edu - Subject: ISIS at UNC-Chapel Hill (long) - Hello Ken. Now that the end-of-semester crunch is past, I thought I - would take a minute and fill you in on our experience using ISIS at - Carolina. This past semester Jennifer Welch and I taught a course, - "Advanced Distributed Systems" (graduate students only), modeled - loosly after Fingerlakes '89. We required a major project and, further, - required that it be done using ISIS. - In a nutshell, it was a very successful experience. ISIS proved to be - a solid, useful tool (even though the choice of project topic was not - a perfect match for ISIS). I have never heard such positive comments - from graduate students forced to use a piece of research software. In - general they were excited about attacking and seeing a solution to real - problems like fault tolerance that are usually only abstract - discussions. Without ISIS we could not have tackled a project of this - scope in a one semester, 3 hour course. Our conclusion is that - ISIS is a very well-executed design and implementation. - I have attached copies of the project assignment. I am also mailing to - you the final report from the best of the teams -- you may be interested in - some of their ISIS comments. - -- Don Smith - ------------------- - COMP 290-2 - Advanced Distributed Systems - Don Smith & Jennifer Welch - Spring 1990 - Class Project Assignment - Your team will design, implement, and verify the operation of the banking - service for computer currencies described in the class handout "A Distributed - Banking System for Computer Currencies" (1/19/90). That document, along with - the project requirements given below, constitute the set of requirements that - should guide your plans. If you have questions or concerns about these - requirements, discuss them with me. While this project touches on aspects - of operating systems, files and databases, user interfaces, etc., please keep - in mind this is a course on distributed systems. I am, therefore, more - interested in your attack on issues such as authentication, authorization, - resource location, interprocess communication, concurrency control, - replication, and fault tolerance than on other aspects. You should also - resist the temptation to provide elaborate bank services -- it is better to - concentrate on core services that are essential andexecute them well than - to have partial success on greater ambitions. It is also proper to establish - limits such as: customers may have no more than X escrow accounts, or there - may be no more than Y currencies in circulation. - Project Requirements: - - provide a highly available service: at a minimum the bank should continue - to provide all services to all users even if one component fails. It should - also continue to provide some services to some set of users even if multiple - components fail. Recovery of failed components should also be non-disruptive - to users. - - - assume that the volume of service requests cannot be handled by a single - server process (or multiple instances running on a single machine). - - assume a large number of concurrent and independent sources of service - requests. - - use the ISIS toolkit as your main implementation tool. You will find that - the ISIS documentation provides hints on its use in dealing with many of the - issues you will face in the implementation. Kerberos is also available for - your use. Do not attempt to use a general data base system (e.g. Ingress). - Documentation on ISIS and Kerberos will be provided soon. - Project Milestones: - There will be three major milestones for the project -- the "deliverable" - for each milestone is a document (with programs for the final report). - 1. Due 2/16/90 -- functional description (the architecture document) that - describes the services and guarantees provided to users (people and programs). - Plan to budget roughly 10-15 pages for this material. - 2. Due 3/23/90 -- design description (the implementation document) and test - plan. The design description should make clear how your team plans to deal - with the issues noted in the first paragraph. The test plan should show how - you will convince users (and me) that the implementation meets the - requirements and architecture. Plan to budget roughly 20-30 pages for this - material. - 3. Due 4/25/90 -- project report (and programs, including test cases, which - can be delivered as path name(s)). The report should include updated - versions of the architecture and implementation documents (yes, I know - things will change), a summary of results from executing your test plan, - and your team's overall evaluation of the project and your results (I am - also interested in your evaluation of the programming tools used). - I would like each team to schedule 2-3 (or more if you want) meetings with - me to discuss questions, problems, progress, etc. You will probably want - some of these meetings to be early in the project. This can be instructive - for all of us. - ------------------- - COMP 290-2 - Advanced Distributed Systems - Don Smith & Jennifer Welch - Spring 1990 - A Distributed Banking System for Computer Currencies - Note: The system described here is based largely on ideas from the Bank - Service that is part of the Amoeba system [1,2], and to some degree on a - similar service discussed for the Andrew system [3] but never implemented. - In large-scale distributed environments such as Andrew, Athena[4], and - Grapevine[5,6], there are many providers of services to users. Some users - own personal computers; others make use of public machines provided by the - administration of an organization, either work stations or shared "compute - servers" providing batch or interactive services. Typically all machines - are interconnected by networks provided as a utility by a central admin- - istration or a federation of local administrations. Services such as - program execution, file storage, electronic mail, document formatting, - printing, etc., may be provided by many sources, including a central - administration, local departments, or even individual users. For example, - I might develop a unique document formatting program capable of accepting - files in many formats (Word, WordPerfect, Lotus, MacDraw,...), transforming - them into a standard representation and storing or printing the result. I - might make this function available to all users by running a server on my - privately-owned computer attached to the public network. - Historically, computer accounting and control has concentrated on the - consumption of primitive resources such as CPU seconds, disk blocks, pages - of paper, etc. Another view that is especially attractive in distributed - environments emphasizes the consumption of services. Services encompass - not just the primitive resources but also intellectual property, development, - maintenance, and support (help). In economic systems, consumption of - resources or services is measured by money (currencies) provided and - transferred through banking systems. A similar notion of money and banking - also applies to services consumed in distributed computer systems. - I might want to make (real) money from the document service described - above. After all, the program represents my intellectual property, it is - running on a computer I purchased, I have to respond to user problems. etc. - Each time a user invokes the service, my program could compute a charge - (based on resource consumption or "value" or both) and demand payment for - performing the job. But I also have to pay my bills -- my service would - use the network, file storage, printers, and paper provided by other - sources. This example also serves to highlight another important property - of services in distributed systems -- they form hierarchies. One service - makes use of other services and resources. A document production service - uses a print service which uses printers and paper. - To facilitate the exchange of services in a computing environment, a - banking system for computer currencies is required. The bank is a third - party trusted by both the user and provider of a service to handle and - safeguard their funds. Users and providers of services maintain accounts - with the bank which provides services for transferring amounts of various - currencies among the accounts. Note that both users and service providers - can be people or programs. - The Distributed Bank Service - The bank service manages account objects for its users. There are two - types of accounts -- private and "escrow". Private accounts are much like - normal bank accounts; generally they are manipulated only by their owners. - Private accounts can be created, and currencies can be deposited into and - withdrawn from them. Both consumers and providers of services own private - accounts. Consumers also own one or more "escrow" accounts, one for each - service that they may use. Funds in these accounts are held in trust by - the bank to pay for services used by the account owner. Providers of - services may request the transfer of funds from an escrow account to their - private account. The bank will do so only if the request is accompanied by - a certification of services performed by the provider. Of course, the - provider may query the bank for balances in the escrow accounts before - performing a service. Owners can request that the bank transfer funds from - their private accounts to their escrow accounts but owners cannot withdraw - funds from escrow accounts. - The bank also manages currencies. Multiple currencies are useful for - placing value on diverse services and resources. For example, one - currency could represent value in disk storage units, another in seconds - of processor time, and yet another in instances of executing a high- - performance compiler. Service providers may require payment in one or - more currencies so accounts must maintain balances in multiple currencies. - - Currencies are also useful for allocating scarce resources. This can be - accomplished by limiting the amount of any currency minted and - in circulation. For example, a file service may require payment in a - currency that is tied directly to the amount of space available on its - disks. Currencies can be created, minted, and removed dynamically. Some - currencies can be converted into others according to exchange rates - established with the bank. One currency must represent real money (e.g., - dollars) and the bank should accept deposits and issue checks in this - currency. If my document processing service is successful, I should be - able to have the bank convert funds in my private account to a check for - deposit in a real bank. - The bank service implements a number of commands for users to request - its functions. A sample is given below: - CreatePrivateAccount - CreateEscrowAccount - TransferFunds - QueryBalance - RemoveAccount - CreateCurrency - MintCurrency - ConvertCurrency -- Kenneth P. Birman E-mail: ken@cs.cornell.edu 4105 Upson Hall, Dept. of Computer Science TEL: 607 255-9199 (office) Cornell University Ithaca, NY 14853 (USA) FAX: 607 255-4428