Transcript CS603 Basics of underlying platforms

CS603
Basics of underlying platforms
January 9, 2002
Course Administration
• Do you prefer an in-class or evening mid-term?
• Is anyone using the course for a Qual1?
• Add yourself to course mailing list:
– Send mail to [email protected] containing the line:
add your email to cs603
• Send me any conflict dates:
– Bad times for the midterm
– Days you will be gone or other big projects so I can schedule
project due dates to avoid conflicts
• Check the latest on the course web page for more
information:
http://www.cs.purdue.edu/homes/clifton/cs603/
Basics of Underlying Platforms
•
•
•
•
Why do we want distributed systems?
Basic hardware concepts
Software concepts
System models
Distributed System Goals
• Connect users and resources
– Why not place resource and user together?
• Multiple users share same resource
• We don’t know where the user will be (ATM)
• Mobile users
• Transparency
– User shouldn’t be aware system is distributed
– Is this always true?
Distributed System Goals
(continued)
• Distributed systems should be open
– Allow user to choose platform
– Separate development of resource/client
• Distributed systems should scale
– Number of users
– Size of resource
– Number of types of clients/servers
Hardware
• What machines are used (nodes)?
– Homogenous
– Client/server
• All clients identical
• Multiple types of clients
– Multi-server
• Replicated servers
• Different resources
Hardware
• How are things connected?
– Is a multiprocessor a distributed system?
– Homogeneous networks (e.g., LAN)
– Different types of networks (wireless, dial-up,
LAN)
• How does this affect system?
– Build to lowest common denominator?
– Different views for different paths?
Violates transparency!
Software concepts
• Distributed operating systems
– Conceptually the ultimate in transparency
• User/programmer view is single system
• OS handles all mapping
– Resource request is system call
– Response comes automatically
– Same code for single site or distributed
– In practice, programmer can see distribution
• Enables concurrent processing
• Shared memory view
• OS provides constructs to support sharing
Software Concepts:
Concurrency Primitives
• Semaphore
– Value with operations: Increment and Decrement
• Decrement blocks if value = 0
– Alternative view: “Test and Set”
– Key: Semaphore operations atomic
• Monitor
– Object (package of values and procedures)
– Atomicity: Only one process may execute object at
any time
Thought exercise: Implement Semaphore with
Monitors
Software Concepts:
Concurrency Primitives
• What went wrong? Blocked processes
• Solution: Additional primitives
– Wait
– Signal
• How does this affect “only one process at
a time”?
– Wait effectively exits monitor
– Resume after wait
Software Concepts
• Problem: How to implement shared memory
across a network?
– Similar to paging, but “paged out” is on a different
machine, not disk
– Need global page table
– Distributed OS handles the details
What does this do to performance?
• Alternative: Expose distribution
– Message passing
– Remote procedure call
Software Concepts
Network Operating System
• No single system view
• Primitives/commands handle distribution
– rsh/rcp: Command level remote procedure
call and remote file transfer
– Primitives for cross-machine concurrency
control (e.g., flock on NFS)
• Big problem: User must be location-aware!
Software Concepts:
Middleware approach
• What does middleware do?
– Doesn’t hide distribution
– Hides location
– Hides heterogeneity
• Examples
–
–
–
–
Unix (and especially Plan 9): Everything is a file
Remote Procedure Call
Distributed Objects
Distributed Documents
CS603
Basics of underlying platforms
January 11, 2002
Distributed System Models
• Client-Server
– Resource sits at a server
– Application sits at a client
– Server waits for client to request resource
• Three-tier Architecture
– Client-(Client-Server)
– Sometimes tighter coupling than client-server
between lower levels
• Peer to Peer
– Everyone is client and server
• What do these have in common?
Distributed System Models:
What is next?
• Push models
– Not just client driven
– Otherwise looks like client-server (or multitier)
• Agent-based models
– Is this anything new?
• Any other ideas?