Outline for February 20, 2001

1. Greetings and felicitations!
   1. Tuesday, Feb 20 3-4:30: Friday Feb 23 1:10-2:30; go to 1101 Hart Hall to view
2. Writing Policy
   1. Write-through: client writes to file, server immediately updates file written
   2. Delayed write at server: client writes to file, server may hold before updating file; idea is that data may not need to be written at all because client may delete it; problem is crashes loose that data
   3. Delayed write at client: writes sit at client until file is closed, then are flushed to server. Idea is that files are open for a very short time, so this cuts burden on servers
3. Cache consistency
   1. server-initiated: servers inform cache managers when data no longer valid
   2. client-initiated: client cache managers check validity of data before returning it to callers
   3. disallow caching when concurrent-write sharing: file open at multiple clients, and at least one for writing (either server tracks who has file open and how, or lock it)
   4. problem: sequential-write sharing: recently updated file (by one client) is opened for writing by a second client. Second may have outdated blocks in cache (cache timestamps, and compare with real timestamps); first client may not have flushed cached changes yet (server requires clients to flush cache when another client opens file)
4. Availability via replication
   1. Replicate files
      1. Can do only those that must be highly available
      2. Some attribute data (e.g., protection rights) stored with each replica
      3. May not reside on same server as containing directory
   2. Replicate volumes (file systems)
      1. Easier to manage (e.g., protection rights associated with volume)
      2. Need to replicate volume if any file on it requires high availability
   3. Replicate filegroups (primary pack; replica called a pack)
      1. Contains subset of files in primary pack
   4. Management: consistency among replicas
      1. Weighted voting scheme
      2. Agent processes (Locus' current storage site enforces the global synchronization policy)
5. Example: NFS
   1. Architecture: built on RPC and using a virtual file interface à la UNIX (vnodes)
   2. Naming: all workstations are (conceptually) clients and servers; in practise, have a few systems designated as file servers (BFS downstairs); discuss file handles; it's stateless
   3. Lack of State: simplifies crash recovery. Handle contains all the info identifying the file, and client kernel tracks file offsets, etc. If client hears nothing, just resend
      1. Server crashes: just restart
      2. Messages bigger than stateful server would require, but would also require restoring lots of info!
   4. Caching: client caches:
      1. File blocks (on demand, usually 8Kb blocks) as is timestamp of last mod on server. Timeout after some period of time, then must revalidate
      2. Directory name lookups; flushed when lookup fails and/or new vnode info obtained
      3. File attributes:90% of all NFS requests to server; discarded after 3 sec (files), 30 sec (directories)
6. Example: Sprite
   1. Architecture: uses a virtual file interface, built on multiple servers
   2. Naming: global tree hierarchy; each subtree is a domain and multiple domains may reside on one server; prefix table maps file prefixes to servers (each entry has full name of mount point, server name, and domain name); to locate, refer to prefix table and find longest matching prefix, then go there n(if no entry, broadcast for it); server sends a file token for the file, and this used to reference file. Remote links return contained file names and client iterates.
   3. Caching: in main memory
      1. File blocks: addressed by file token and block number. Query is to cache, then local (if there) or remote; if remote, to cache, then to file
      2. Delayed writing policy: every 5 sec, cached blocks not modified in last 30 sec are written back to server
      3. Replacement policy: LRU
      4. Consistency: server-initiated approach; files open for both reading and writing are not cached and when opened for such, cached blocks are written back before open finished
7. Example: Coda (descendant of AFS)
   1. Architecture: highly scalable so clients take much of load through caching; local client's disk treated entirely as a cache and clients can operate when disconnected
   2. Naming: uses volumes; each file, directory has a 92-bit File ID (32 bit volume number, 32 bit vnode number, 32 bit unique identifier). Replication preserves FIDs. Servers have volume location databases. name components mapped to FIDs and this info cached at client.
   3. Caching: on volume creation, number and location of volume replicas is set (called a volume replication database; set of servers called a volume storage group; set of servers accessible to a client for every cached volume is called accesible volume storage group and is kept track of by client cache manager, called Venus)
      1. On demand caching, files cached in their entirety on client
      2. Obtained from a preferred server (one of the AVSG); if contacted one is not newest copy, because some other member has a newer one, that server becomes preferred server and previous preferred server notified it has stale data
      3. Callbacks: set at preferred server, agreement to notify client if file becomes stale; then client invalidates cached file, may get new copy
      4. On modification, file sent back to all members of AVSG in parallel (via hardware multicast)
8. Security
   1. Goals: confidentiality, integrity, availability
   2. Basic Outline: Foundations, Policies, Mechanisms, Assurance, Human and Operational Issues
   3. Relationship of policy and mechanism and assurance
   4. Foundations: ACM model, HRU result
   5. Policies: BLP (confidentiality), Clark-Wilson (integrity), Chinese Wall (both)
   6. Mechanism: cryptography
9. Cryptography
   1. basics (cryptosystems, attacks, codes vs. ciphers, superencryption)
   2. substitution ciphers (Cæsar cipher, Vigenère cipher)
   3. transposition ciphers (rail-fence cipher)
   4. product cipher (DES)
   5. public key crypto (RSA, DH)
   6. cryptographic checksums
   7. key management (Kerberos, PKI)
   8. digital signatures
   9. authentication
   10. Examples: PEM, PGP, IPSec

Matt Bishop Office: 3059 Engineering Unit II Phone: +1 (530) 752-8060 Fax: +1 (530) 752-4767 Email: bishop@cs.ucdavis.edu

Copyright Matt Bishop, 2001. All federal and state copyrights reserved for all original material presented in this course through any medium, including lecture or print.