distributed operating system_4
DESCRIPTION
DISTRIBUTED OPERATING SYSTEMS TRANSPARENCY IN A DISTRIBUTED SYSTEM DISTRIBUTED SYSTEMS MODELS COMMUNICATION IN DISTRIBUTED SYSTEMS GROUP COMMUNICATIONTRANSCRIPT
![Page 1: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/1.jpg)
DISTRIBUTED OPERATING
SYSTEMS
Sandeep Kumar PooniaHead of Dept. CS/IT
B.E., M.Tech., UGC-NET
LM-IAENG, LM-IACSIT,LM-CSTA, LM-AIRCC, LM-SCIEI, AM-UACEE
![Page 2: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/2.jpg)
DEFINITION OF A DISTRIBUTED SYSTEM
A distributed system:
Multiple connected CPUs working together
A collection of independent computers that
appears to its users as a single coherent
system
Examples: parallel machines, networked
machines
![Page 3: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/3.jpg)
ADVANTAGES AND DISADVANTAGES
Advantages
Communication and resource sharing possible
Economics – price-performance ratio
Reliability, scalability
Potential for incremental growth
Disadvantages
Distribution-aware PLs, OSs and applications
Network connectivity essential
Security and privacy
![Page 4: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/4.jpg)
TRANSPARENCY IN A DISTRIBUTED SYSTEM
Different forms of transparency in a distributed system.
Transparency Description
AccessHide differences in data representation and how a resource is accessed
Location Hide where a resource is located
Migration Hide that a resource may move to another location
RelocationHide that a resource may be moved to another location while in use
Replication User cannot tell how many copies exist
Concurrency Hide that a resource may be shared by several competitive users
Failure Hide the failure and recovery of a resource
Persistence Hide whether a (software) resource is in memory or on disk
![Page 5: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/5.jpg)
![Page 6: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/6.jpg)
SCALABILITY PROBLEMS
Examples of scalability limitations.
Concept Example
Centralized services A single server for all users
Centralized data A single on-line telephone book
Centralized algorithms Doing routing based on complete information
![Page 7: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/7.jpg)
HARDWARE CONCEPTS: MULTIPROCESSORS (1)
Multiprocessor dimensions
Memory: could be shared or be private to each CPU
Interconnect: could be shared (bus-based) or switched
A bus-based multiprocessor.
![Page 8: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/8.jpg)
MULTIPROCESSORS (2)
a) A crossbar switch b) An omega switching
network
1.8
![Page 9: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/9.jpg)
DISTRIBUTED SYSTEMS MODELS
Minicomputer model (e.g., early networks)
Each user has local machine
Local processing but can fetch remote data (files, databases)
Workstation model (e.g., Sprite)
Processing can also migrate
Client-server Model (e.g., V system, world wide web)
User has local workstation
Powerful workstations serve as servers (file, print, DB servers)
Processor pool model (e.g., Amoeba, Plan 9)
Terminals are Xterms or diskless terminals
Pool of backend processors handle processing
![Page 10: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/10.jpg)
UNIPROCESSOR OPERATING SYSTEMS
An OS acts as a resource manager or an arbitrator
Manages CPU, I/O devices, memory
OS provides a virtual interface that is easier to use
than hardware
Structure of uniprocessor operating systems
Monolithic (e.g., MS-DOS, early UNIX)
One large kernel that handles everything
Layered design
Functionality is decomposed into N layers
Each layer uses services of layer N-1 and implements
new service(s) for layer N+1
![Page 11: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/11.jpg)
UNIPROCESSOR OPERATING SYSTEMS
Microkernel architecture
• Small kernel
• user-level servers implement additional functionality
![Page 12: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/12.jpg)
DISTRIBUTED OPERATING SYSTEM
Manages resources in a distributed system
Seamlessly and transparently to the user
Looks to the user like a centralized OS
But operates on multiple independent CPUs
Provides transparency
Location, migration, concurrency, replication,…
Presents users with a virtual uniprocessor
![Page 13: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/13.jpg)
DOS: CHARACTERISTICS (1)
Distributed Operating Systems
Allows a multiprocessor or multicomputer network
resources to be integrated as a single system image
Hide and manage hardware and software resources
provides transparency support
provide heterogeneity support
control network in most effective way
consists of low level commands + local operating systems +
distributed features
Inter-process communication (IPC)
![Page 14: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/14.jpg)
DOS: CHARACTERISTICS (2)
remote file and device access
global addressing and naming
trading and naming services
synchronization and deadlock avoidance
resource allocation and protection
global resource sharing
deadlock avoidance
communication security
no examples in general use but many research systems: Amoeba, Chorus etc.
![Page 15: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/15.jpg)
TYPES OF DISTRIBUTED OS
System Description Main Goal
DOSTightly-coupled operating system for multi-processors and homogeneous multicomputers
Hide and manage hardware resources
NOSLoosely-coupled operating system for heterogeneous multicomputers (LAN and WAN)
Offer local services to remote clients
MiddlewareAdditional layer atop of NOS implementing general-purpose services
Provide distribution transparency
![Page 16: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/16.jpg)
MULTIPROCESSOR OPERATING SYSTEMS
Like a uniprocessor operating system
Manages multiple CPUs transparently to the
user
Each processor has its own hardware cache
Maintain consistency of cached data
![Page 17: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/17.jpg)
MULTICOMPUTER OPERATING SYSTEMS
1.14
![Page 18: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/18.jpg)
NETWORK OPERATING SYSTEM
1-19
![Page 19: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/19.jpg)
NETWORK OPERATING SYSTEM
Employs a client-server model
Minimal OS kernel
Additional functionality as user processes
![Page 20: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/20.jpg)
MIDDLEWARE-BASED SYSTEMS
General structure of a distributed system as middleware.
1-22
![Page 21: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/21.jpg)
MIDDLEWARE EXAMPLES Examples: Sun RPC, CORBA, DCOM, Java RMI (distributed
object technology)
Built on top of transport layer in the ISO/OSI 7 layer reference model: application (protocol), presentation (semantic), session (dialogue), transport (e.g. TCP or UDP), network (IP, ATM etc), data link (frames, checksum), physical (bits and bytes)
Most are implemented over the internet protocols
Masks heterogeneity of underlying networks, hardware, operating system and programming languages – so provides a uniform programming model with standard services
3 types of middleware: transaction oriented (for distributed database applications)
message oriented (for reliable asynchronous communication)
remote procedure calls (RPC) – the original OO middleware
![Page 22: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/22.jpg)
COMPARISON BETWEEN SYSTEMS
Item
Distributed OS
Network OSMiddleware-based OS
Multiproc. Multicomp.
Degree of transparency Very High High Low High
Same OS on all nodes Yes Yes No No
Number of copies of OS 1 N N N
Basis for communicationShared memory
Messages Files Model specific
Resource managementGlobal, central
Global, distributed
Per node Per node
Scalability No Moderately Yes Varies
Openness Closed Closed Open Open
![Page 23: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/23.jpg)
COMMUNICATION IN DISTRIBUTED SYSTEMS
Issues in communication
Message-oriented Communication
Remote Procedure Calls
Transparency but poor for passing references
Remote Method Invocation
RMIs are essentially RPCs but specific to remote
objects
System wide references passed as parameters
Stream-oriented Communication
![Page 24: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/24.jpg)
TYPES OF COMMUNICATION
Message passing is the general basis of
communication in a distributed system: transferring a
set of data from a sender to a receiver.
![Page 25: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/25.jpg)
COMMUNICATION BETWEEN PROCESSES
Unstructured communication
Use shared memory or shared data structures
Structured communication
Use explicit messages (IPCs)
Distributed Systems: both need low-level
communication support
![Page 26: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/26.jpg)
COMMUNICATION PROTOCOLS
Protocols are agreements/rules on communication
Protocols could be connection-oriented or connectionless
2-1
![Page 27: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/27.jpg)
LAYERED PROTOCOLS
A typical message as it appears on the network.
2-2
![Page 28: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/28.jpg)
Physical layer
The physical layer is responsible for movements of
individual bits from one hop (node) to the next.
![Page 29: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/29.jpg)
PHYSICAL LAYER
Provides physical interface for transmission of information.
Defines rules by which bits are passed from one system toanother on a physical communication medium.
Covers all - mechanical, electrical, functional andprocedural - aspects for physical communication.
Such characteristics as voltage levels, timing of voltagechanges, physical data rates, maximum transmissiondistances, physical connectors, and other similar attributesare defined by physical layer specifications.
OSI Model
![Page 30: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/30.jpg)
Data link layer
The data link layer is responsible for moving
frames from one hop (node) to the next and perform error
detection and correction
![Page 31: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/31.jpg)
DATA LINK LAYER
Data link layer attempts to provide reliable communicationover the physical layer interface.
Breaks the outgoing data into frames and reassemble thereceived frames.
Create and detect frame boundaries.
Handle errors by implementing an acknowledgement andretransmission scheme.
Implement flow control.
Supports points-to-point as well as broadcastcommunication.
Supports simplex, half-duplex or full-duplex communication.
OSI Model
![Page 32: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/32.jpg)
DATA LINK LAYER
![Page 33: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/33.jpg)
Network layer
The network layer is responsible for the
delivery of individual packets from
the source host to the destination host.
Protocols: X.25Connection oriented
IP Connection Less
![Page 34: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/34.jpg)
NETWORK LAYER
Implements routing of frames (packets) through thenetwork.
Defines the most optimum path the packet should takefrom the source to the destination
Defines logical addressing so that any endpoint can beidentified.
Handles congestion in the network.
Facilitates interconnection between heterogeneousnetworks (Internetworking).
The network layer also defines how to fragment a packetinto smaller packets to accommodate different media.
OSI Model
![Page 35: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/35.jpg)
Source-to-destination delivery
![Page 36: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/36.jpg)
Transport layer
The transport layer is responsible for the delivery
of a message from one process to another.
Protocols: TCP Connection oriented
UDP Connection Less
![Page 37: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/37.jpg)
TRANSPORT LAYER
Purpose of this layer is to provide a reliable mechanism forthe exchange of data between two processes in differentcomputers.
Ensures that the data units are delivered error free.
Ensures that data units are delivered in sequence.
Ensures that there is no loss or duplication of data units.
Provides connectionless or connection oriented service.
Provides for the connection management.
Multiplex multiple connection over a single channel.
OSI Model
![Page 38: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/38.jpg)
Reliable process-to-process delivery of a message
![Page 39: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/39.jpg)
Session layer
The session layer is responsible for dialog
control and synchronization.
![Page 40: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/40.jpg)
SESSION LAYER
Session layer provides mechanism for controlling the dialoguebetween the two end systems. It defines how to start, controland end conversations (called sessions) between applications.
This layer requests for a logical connection to be established onan end-user’s request.
Any necessary log-on or password validation is also handled bythis layer.
Session layer is also responsible for terminating the connection.
This layer provides services like dialogue discipline which can befull duplex or half duplex.
Session layer can also provide check-pointing mechanism suchthat if a failure of some sort occurs between checkpoints, alldata can be retransmitted from the last checkpoint.
OSI Model
![Page 41: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/41.jpg)
Presentation layer
The presentation layer is responsible for translation,
compression, and encryption.
![Page 42: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/42.jpg)
PRESENTATION LAYER
Presentation layer defines the format in which the data is tobe exchanged between the two communicating entities.
Also handles data compression and data encryption(cryptography).
OSI Model
![Page 43: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/43.jpg)
Application layer
The application layer is responsible for
providing services to the user.
![Page 44: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/44.jpg)
APPLICATION LAYER
Application layer interacts with application programs and isthe highest level of OSI model.
Application layer contains management functions tosupport distributed applications.
Examples of application layer are applications such as filetransfer, electronic mail, remote login etc.
OSI Model
![Page 45: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/45.jpg)
Summary of layers
![Page 46: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/46.jpg)
MIDDLEWARE PROTOCOLS
Middleware: layer that resides between an OS and an application
May implement general-purpose protocols that warrant their own layers
Example: distributed commit
2-5
![Page 47: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/47.jpg)
CLIENT-SERVER COMMUNICATION MODEL
Structure: group of servers offering service to
clients
Based on a request/response paradigm
Techniques:
Socket, remote procedure calls (RPC), Remote
Method Invocation (RMI)
kernel
client
kernel kernel kernel
file
server
process
server
terminal
server
![Page 48: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/48.jpg)
ISSUES IN CLIENT-SERVER COMMUNICATION
Addressing
Blocking versus non-blocking
Buffered versus unbuffered
Reliable versus unreliable
Server architecture: concurrent versus
sequential
Scalability
![Page 49: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/49.jpg)
ADDRESSING ISSUES
Question: how is the server
located?
Hard-wired address
Machine address and process
address are known a priori
Broadcast-based
Server chooses address from a
sparse address space
Client broadcasts request
Can cache response for future
Locate address via name
server
user server
user server
user serverNS
![Page 50: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/50.jpg)
![Page 51: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/51.jpg)
BLOCKING VERSUS NON-BLOCKING
Blocking communication (synchronous)
Send blocks until message is actually sent
Receive blocks until message is actually received
Non-blocking communication (asynchronous)
Send returns immediately
Return does not block either
![Page 52: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/52.jpg)
![Page 53: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/53.jpg)
![Page 54: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/54.jpg)
BUFFERING ISSUES
Unbuffered
communication
Server must call receive
before client can call send
Buffered communication
Client send to a mailbox
Server receives from a
mailbox
user server
user server
![Page 55: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/55.jpg)
RELIABILITY
Unreliable channel
Need acknowledgements (ACKs)
Applications handle ACKs
ACKs for both request and reply
Reliable channel
Reply acts as ACK for request
Explicit ACK for response
Reliable communication on unreliable channels
Transport protocol handles lost messages
request
ACK
reply
ACK
User
Se
rve
r
request
reply
ACK
User
Serv
er
![Page 56: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/56.jpg)
![Page 57: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/57.jpg)
SERVER ARCHITECTURE Sequential
Serve one request at a time
Can service multiple requests by employing events and
asynchronous communication
Concurrent
Server spawns a process or thread to service each request
Can also use a pre-spawned pool of threads/processes
(apache)
Thus servers could be
Pure-sequential, event-based, thread-based, process-based
Discussion: which architecture is most efficient?
![Page 58: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/58.jpg)
SCALABILITY
Question:How can you scale the server
capacity?
Buy bigger machine!
Replicate
Distribute data and/or algorithms
Ship code instead of data
Cache
![Page 59: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/59.jpg)
TO PUSH OR PULL ?
Client-pull architecture
Clients pull data from servers (by sending requests)
Example: HTTP
Pro: stateless servers, failures are each to handle
Con: limited scalability
Server-push architecture
Servers push data to client
Example: video streaming, stock tickers
Pro: more scalable, Con: stateful servers, less resilient to
failure
When/how-often to push or pull?
![Page 60: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/60.jpg)
GROUP COMMUNICATION
One-to-many communication: useful for
distributed applications
Issues:
Group characteristics:
Static/dynamic, open/closed
Group addressing
Multicast, broadcast, application-level multicast (unicast)
Atomicity
Message ordering
Scalability
![Page 61: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/61.jpg)
PUTTING IT ALL TOGETHER: EMAIL
User uses mail client to compose a message
Mail client connects to mail server
Mail server looks up address to destination
mail server
Mail server sets up a connection and passes
the mail to destination mail server
Destination stores mail in input buffer (user
mailbox)
Recipient checks mail at a later time
![Page 62: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/62.jpg)
EMAIL: DESIGN CONSIDERATIONS
Structured or unstructured?
Addressing?
Blocking/non-blocking?
Buffered or unbuffered?
Reliable or unreliable?
Server architecture
Scalability
Push or pull?
Group communication
![Page 63: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/63.jpg)
REMOTE PROCEDURE CALLS
Goal: Make distributed computing look like centralized
computing
Allow remote services to be called as procedures
Transparency with regard to location, implementation,
language
Issues
How to pass parameters
Bindings
Semantics in face of errors
Two classes: integrated into prog, language and
separate
![Page 64: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/64.jpg)
CONVENTIONAL PROCEDURE CALL
a) Parameter passing in a local
procedure call: the stack before the
call to read
b) The stack while the called procedure is
active
![Page 65: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/65.jpg)
PARAMETER PASSING
Local procedure parameter passing
Call-by-value
Call-by-reference: arrays, complex data structures
Remote procedure calls simulate this through:
Stubs – proxies
Flattening – marshalling
Related issue: global variables are not allowed
in RPCs
![Page 66: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/66.jpg)
CLIENT AND SERVER STUBS
Principle of RPC between a client and server program.
![Page 67: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/67.jpg)
STUBS
Client makes procedure call (just like a local
procedure call) to the client stub
Server is written as a standard procedure
Stubs take care of packaging arguments and
sending messages
Packaging parameters is called marshalling
Stub compiler generates stub automatically
from specs in an Interface Definition Language
(IDL)
Simplifies programmer task
![Page 68: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/68.jpg)
STEPS OF A REMOTE PROCEDURE CALL1. Client procedure calls client stub in normal way
2. Client stub builds message, calls local OS
3. Client's OS sends message to remote OS
4. Remote OS gives message to server stub
5. Server stub unpacks parameters, calls server
6. Server does work, returns result to the stub
7. Server stub packs it in message, calls local OS
8. Server's OS sends message to client's OS
9. Client's OS gives message to client stub
10. Stub unpacks result, returns to client
![Page 69: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/69.jpg)
EXAMPLE OF AN RPC
2-8
![Page 70: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/70.jpg)
MARSHALLING
Problem: different machines have different data formats
Intel: little endian, SPARC: big endian
Solution: use a standard representation
Example: external data representation (XDR)
Problem: how do we pass pointers?
If it points to a well-defined data structure, pass a copy and the server
stub passes a pointer to the local copy
What about data structures containing pointers?
Prohibit
Chase pointers over network
Marshalling: transform parameters/results into a byte stream
![Page 71: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/71.jpg)
BINDING
Problem: how does a client locate a server?
Use Bindings
Server
Export server interface during initialization
Send name, version no, unique identifier, handle (address)
to binder
Client
First RPC: send message to binder to import server interface
Binder: check to see if server has exported interface
Return handle and unique identifier to client
![Page 72: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/72.jpg)
BINDING: COMMENTS
Exporting and importing incurs overheads
Binder can be a bottleneck
Use multiple binders
Binder can do load balancing
![Page 73: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/73.jpg)
FAILURE SEMANTICS
Client unable to locate server: return error
Lost request messages: simple timeout mechanisms
Lost replies: timeout mechanisms
Make operation idempotent
Use sequence numbers, mark retransmissions
Server failures: did failure occur before or after
operation?
At least once semantics (SUNRPC)
At most once
No guarantee
Exactly once: desirable but difficult to achieve
![Page 74: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/74.jpg)
FAILURE SEMANTICS
Client failure: what happens to the server
computation?
Referred to as an orphan
Extermination: log at client stub and explicitly kill orphans
Overhead of maintaining disk logs
Reincarnation: Divide time into epochs between failures
and delete computations from old epochs
Gentle reincarnation: upon a new epoch broadcast, try to
locate owner first (delete only if no owner)
Expiration: give each RPC a fixed quantum T; explicitly
request extensions
Periodic checks with client during long computations
![Page 75: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/75.jpg)
IMPLEMENTATION ISSUES
Choice of protocol [affects communication costs]
Use existing protocol (UDP) or design from scratch
Packet size restrictions
Reliability in case of multiple packet messages
Flow control
Copying costs are dominant overheads
Need at least 2 copies per message
From client to NIC and from server NIC to server
As many as 7 copies
Stack in stub – message buffer in stub – kernel – NIC – medium –NIC – kernel – stub – server
Scatter-gather operations can reduce overheads
![Page 76: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/76.jpg)
CASE STUDY: SUNRPC
One of the most widely used RPC systems
Developed for use with NFS
Built on top of UDP or TCP
TCP: stream is divided into records
UDP: max packet size < 8912 bytes
UDP: timeout plus limited number of retransmissions
TCP: return error if connection is terminated by server
Multiple arguments marshaled into a single structure
At-least-once semantics if reply received, at-least-zero semantics if no reply. With UDP tries at-most-once
Use SUN’s eXternal Data Representation (XDR)
Big endian order for 32 bit integers, handle arbitrarily large data structures
![Page 77: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/77.jpg)
BINDER: PORT MAPPER
Server start-up: create port
Server stub calls svc_register
to register prog. #, version #
with local port mapper
Port mapper stores prog #,
version #, and port
Client start-up: call
clnt_create to locate server
port
Upon return, client can call
procedures at the server
![Page 78: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/78.jpg)
RPCGEN: GENERATING STUBS
Q_xdr.c: do XDR conversion
Detailed example: later in this course
![Page 79: Distributed Operating System_4](https://reader034.vdocuments.us/reader034/viewer/2022052321/555578e7b4c9058a5a8b4f4d/html5/thumbnails/79.jpg)
SUMMARY
RPCs make distributed computations look like
local computations
Issues:
Parameter passing
Binding
Failure handling
Case Study: SUN RPC