InterProcess Communications 1. Outline IPC fundamentals UNIX sockets Remote procedural call Shared...
-
Upload
clinton-warren -
Category
Documents
-
view
226 -
download
0
Transcript of InterProcess Communications 1. Outline IPC fundamentals UNIX sockets Remote procedural call Shared...
InterProcess Communications
1
Outline
IPC fundamentals UNIX sockets Remote procedural call Shared memory and large memory spaces IPC in Windows NT Shared memory IPC Shared memory and large address spaces Windows NT IPC Mechanisms
2
IPC Fundamentals
What is IPC?Mechanisms to transfer data between
processesWhy is it needed?
Not all important procedures can be easily built in a single process
3
Why do processes communicate?
To share resourcesClient/server paradigmsInherently distributed applicationsReusable software componentsOther good software engineering
reasons
4
The Basic Concept of IPC
A process needs to send data to a receiving process
Sender wants to avoid details of receiver’s condition
Receiver wants to get the data in an organized way
5
IPC from the OS Point of View
OS address space
Process A Process B
Private address space
Private address space
6
Fundamental IPC Problem for the OS
Each process has a private address space
Normally, no process can write to another process’s space
How to get important data from process A to process B?
7
OS Solutions to IPC Problem
Fundamentally, two options
1. Support some form of shared address space Shared memory
2. Use OS mechanisms to transport data from one address space to another Files, messages, pipes, RPC
8
Fundamental Differences in OS Treatment of IPC Solutions Shared memory
OS has job of setting it up And perhaps synchronizing But not transporting data
Messages, etc OS involved in every IPC OS transports data
9
Desirable IPC Characteristics
Fast Easy to use Well defined synchronization model Versatile Easy to implement Works Remotely
10
IPC and Synchronization
Synchronization is a major concern for IPC Allowing sender to indicate when data is
transmitted Allowing receiver to know when data is ready Allowing both to know when more IPC is
possible
11
IPC and Connections
IPC mechanisms can be connection less or require connection Connectionless IPC mechanisms require no
preliminary setup Connection IPC mechanisms require
negotiation and setup before data flows
12
Connectionless IPC
Data simply flows Typically, no permanent data structures
shared in OS by sender and receiver
+ Good for quick, short communication
+ Less long-term OS overhead
- Less efficient for large, frequent communications
- Each communication takes more OS resources per byte
13
Connection-Oriented IPC
Sender and receiver pre-arrange IPC delivery details
OS typically saves IPC-related information for them
Advantages/disadvantages pretty much the opposites of connectionless IPC
14
Basic IPC Mechanisms
File system IPC Message-based IPC Procedure call IPC Shared memory IPC
15
IPC Through the File System
Sender writes to a file Receiver reads from it But when does the receiver do the read?
Often synchronized with file locking or lock files
Special types of files can make file-based IPC easier
16
File IPC Diagram
Process A Process BData
17
Message-Based IPC
Sender formats data into a formal message With some form of address for receiver
OS delivers message to receiver’s message input queue (might signal too)
Receiver (when ready) reads a message from the queue
Sender might or might not block
18
Message-Based IPC Diagram
Process A Process BData sentfrom A to B
OS
B’s message queue
19
File IPC Diagram
Process A Process B
Data as parametersmain () {
.call();...
}
.
.
.server();...Data as return values
20
Shared Memory IPC
Different processes share a common piece of memory Either physically or virtually
Communications via normal reads/writes May need semaphores or locks
In or associated with the shared memory
21
Shared Memory IPC Diagram
Process A Process B
write variable xmain () {
.x = 10...
}
.
.
.print(x);...
read variable x
x: 10
22
Synchronizing in IPC
How do sending and receiving process synchronize their communications?
Many possibilities Based on which process block when
Examples that follow in message context, but more generally applicable
23
Blocking Send, Blocking Receive
Both sender and receiver block Sender blocks till receiver receives Receiver blocks until sender sends Often called message rendezvous
24
Non-Blocking Send, Blocking Receive
Sender issues send, can proceed without waiting to discover fate of message
Receiver waits for message arrival before proceeding Essentially, receiver is message-driven
25
Non-Blocking Send, Non-Blocking Receive Neither party blocks Sender proceeds after sending message Receiver works until message arrives
Either receiver periodically checks in non-blocking fashion
Or some form of interrupt delivered
26
Addressing in IPC
How does the sender specify where the data goes?
In some cases, the mechanism makes it explicit (e.g., shared memory and RPC)
In others, there are options
27
Direct Addressing
Sender specifies name of the receiving process
Using some form of unique process name Receiver can either specify name of expected
sender Or take stuff from anyone
28
Indirect Addressing
Data is sent to queues, mailboxes, or some other form of shared data structure
Receiver performs some form of read operations on that structure
Much more flexible than direct addressing
29
Duality in IPC Mechanisms
Many aspects of IPC mechanisms are duals of each other
Which implies that these mechanisms have the same power
First recognized in context of messages vs. procedure calls
At least, IPC mechanisms can be simulated by each other
30
So which IPC mechanism to build/choose/use?
Depends on model of computation
And on philosophy of user
In particular cases, hardware or existing software may make one perform better
31
Typical UNIX IPC Mechanisms
Different versions of UNIX introduced different IPC mechanisms Pipes Message queues Semaphores Shared memory Sockets RPC
32
Pipes
Only IPC mechanism in early UNIX systems (other than files) Uni-directional Unformatted Un interpreted Inter process byte streams
Accessed in file-like way
33
Pipe Details
One process feeds bytes into pipe
A second process reads the bytes from it
Potentially blocking communication mechanism
Requires close cooperation between processes to set up Named pipes allow more flexibility
34
Pipes and Blocking
Writing more bytes than pipe capacity blocks the sender Until the receiver reads some of them
Reading bytes when none are available blocks the receiver Until the sender writes some
Single pipe can’t cause deadlock
35
UNIX Message Queues
Introduced in System V Release 3 UNIX
Like pipes, but data organized into messages
Message component include: Type identifier Length Data
36
Semaphores
Also introduced in System V Release 3 UNIX
Mostly for synchronization only Since they only communicate one bit of
information
Often used in conjunction with shared memory
37
UNIX Shared Memory Also introduced in System V Release 3
Allows two or more processes to share some memory segments
With some control over read/write permissions
Often used to implement threads packages for UNIX
38
Sockets Introduced in 4.3 BSD
A socket is an IPC channel with generated endpoints
Great flexibility in it characteristics Intended as building block for communication
Endpoints established by the source and destination processes
39
UNIX Remote Procedure Calls
Procedure calls from one address space to another On the same or different machines
Requires cooperation from both processes
In UNIX, often built on sockets
Often used in client/server computing
40
More on Sockets
Created using the socket() system call
Specifying domain, type, and protocol
Sockets can be connected or connectionless Each side responsible for proper setup/access
41
Socket Domains
the socket domain describes a protocol family used by the socket Generally related to the address family
Domains can be: Internal protocols Internet protocols IMP link layer protocols
42
Socket Types
The socket type describes what the socket does
Several types are defined SOCK_STREAM SOCK_DGRAM SOCK_SEQPACKET SOCK_RAW SOCK_RDM
43
Socket Protocols
This parameter specifies a particular protocol to be used by the socket
Must match other parameters Not all protocols usable with all domains and
types Generally, only one protocol per socket type
available
44
Some Examples of Sockets
Socket streams
Socket sequential packets
Socket datagrams
45
Socket Streams
Of type SOCK_STREAM
Full-duplex reliable byte streams
Like 2-way pipes
Requires other side to connect
46
Socket Sequential Packets
Similar to streams
But for fixed-sized packets
So reads always return a fixed number of bytes
Allow easy use of buffers
47
Socket Datagrams
Like sequential packets
But non-reliable delivery
Which implies certain simplifications
And lower overhead
send(), rather than write(), used to send data
48
Socket Options
Connection or connectionless
Blocking or non-blocking
Out-of-band information
Broadcast
Buffer sizes (input and output)
Routing options
And others 49
Binding Sockets
Binding is the process of preparing a socket for
use by a process
Sockets are typically bound to local names
For IPC on a single machine
Often accessed using descriptors
Requires clean-up when done
Binding can be to IP addresses, as well50
Connecting to Sockets
Method for setting up the receiving end of a
socket
In local domain, similar to opening file
Multiple clients can connect to a socket
Program establishing socket can limit connections
51
Remote Procedural Call
Method of calling procedures in other address
spaces
Either on the same machine
Or other machines
Attempts to provide interface just like local
procedure call
Request/reply communications model52
Semantics of RPC
Similar to regular procedure call
1. Calling procedure blocks
2. Set of parameters transferred to called
procedure
3. Called procedure computes till it returns
4. Return value delivered to calling procedure
5. Calling procedure continues53
High-Level RPC Mechanics
Hide details from applications
Clients pass requests to stub programs
Client-end stub sends request to server stub
Server-end stub calls user-level server
Results travel in reverse direction
Network transport or OS actually moves data
54
Diagram of RPC in Action
Server (callee)Client (caller)
OS or Network
Server stubClient stub
call reply callreply
55
What do the stubs do?
Stubs handle complex details like:
Marshaling arguments
Message construction
Data format translation
Finding the server process
56
Setting Up RPC
Caller must have a way to find the called
procedure
But it can’t be found at link time
Unlike local procedure
Potential servers must make their presence
known
57
Registering Servers
Either register the server at a “well-known” port
Or register it with a name server
Which in turn is at a “well-known” port
Calling procedure “addresses” RPC to that port
58
Binding to a Service
A client process binds to the service it wants Two major sub-problem:
Naming Location
59
Binding: The Naming Problem
How does a caller name the server program? Depends on the RPC mechanism
And perhaps the protocol or type within it Do you name the server explicitly? Or do you name the service and let some
other authority choose which server?
60
Binding: The Location Problem
Where is the remote server? Some naming schemes make it explicit
Some don’t If it’s not explicit, system must convert
symbolic names to physical locations
61
Binding in Cedar RPC
Client applications bind to a symbolic name Composed of:
Type Instance
Type is which kind of service Instance is which particular implementer
62
Locating Cedar RPC Service
Names do not contain physical location So Cedar consults a database of services Services register with database Binding call automatically looks up location in
database
63
Binding in UNIX RPC
bind() system call used by servers Allows servers to bind naming/location
information to particular socket connect() system call used by clients
Using information similar to that bound by the server
Automatic code generation hides details
64
UNIX Binding Information
Like most socket operations, it’s flexible Fill in all or part of a socket address data
structure Create an appropriate socket Then call bind to link socket to address
information connect works similarly
65
UNIX Binding Example
On server side,
struct sockaddr_un sin;
int sd;
strcpy(sin.sun_path,”./socket”);
sd = socket(AF_UNIX, SOCK_STREAM, 0);
bind(sd, &sin, sizeof(sin));
66
UNIX Binding Example, Con’t
For client side,
struct sockaddr_un sin;
int sd;
strcpy(sin.sun_path, “./socket”);
sd = socket(AF_UNIX, SOCK_STREAM, 0);
connect(sd, &sin, sizeof(sin));
67
Locating Remove Services in UNIX RPC Similar to Cedar methods Register services with the portmapper The portmapper is typically called through
automatically generated code the portmapper runs on each machine Another service (e.g., NIS) deals with
intermachine requests
68
Using RPC
Once it’s bound, how does the client use RPC?
Just call the routines As if they were local
And the results come back
69
What’s happening under the covers?
When a client calls a remote routine, he really calls a local stub program
Stub program packages up request to remote server
And sends it to local transport code When reply arrives, local transport code
returns results to stub Which returns to client program
70
What happens at the server side?
A request comes in to the RPC transport code It routes it to the appropriate server stub Which converts it into a local procedure call Which is made within the context of the
server
71
Conceptual Diagram of RPC
call_procedure();
Message from client stub to server stub
call_procedure();
Message received by server stub
Network transport
client program continues
Return value formatted as message to client stub
Network transport
Client stub converts message to return value
return(…);
72
Transport for RPC
In Cedar, special-purpose RPC transport protocol
In UNIX RPC, can use either UDP or TCP for transport Typically protocol is chosen automatically by
stub generator program
73
Other RPC Issues
Mostly related to intermachine RPC Data format conversions Security and authentication Locating remote services Multipacket RPC
74
Shared Memory
A simple and powerful form of IPC Most multiprogramming OS’s use some form
of shared memory E.g., sharing executables
Not all OS’s make shared memory available to applications
75
Shared Memory Diagram
Process A Process B
x: 10 y: 20z: __
a: __ b: __
76
Problems with Shared Memory
Synchronization Protection Pointers
77
Synchronization
Shared memory itself does not provide synchronization of communications
Except at the single-word level Typically, some other synchronization
mechanism is used E.g., semaphore in UNIX Events, semaphores, or hardware locks in
Windows NT
78
Protection
Who can access a segment? And in what ways?
UNIX allows some read/write controls Windows NT has general security monitoring
based on the object-status of shared memory
79
Pointers in Shared Memory
Pointers in a shared memory segment can be troublesome
For that matter, pointers in any IPC can be troublesome
80
Shared Memory Containing Pointers
Process A Process B
x: 10 y: 20z: __
a: __ b: __
w: 5
81
A Troublesome Pointer
Process A Process B
x: 10 y: 20z: __
a: __ b: __
w: 5
82
So, how do you share pointers?
Several methods are in use Copy-time translation Reference-time translation Pointer swizzling
All involve somehow translating pointers at some point before they are used
83
Copy-Time Pointer Translation
When a process sends data containing pointers to another process
Locate each pointer within old version of the data
Then translate pointers are required Requires both sides to traverse entire
structure Not really feasible for shared memory
84
Reference-Time Translation
Encode pointers in shared memory segment as pointer surrogates
Typically as offsets into some other segment in separate contexts
So each sharer can have its own copy of what is pointed to
Slow, pointers in two formats
85
Pointer Swizzling
Like reference-time, but cache results in the memory location
Only first reference is expensive But each sharer must have his own copy Must “unswizzle” pointers to transfer data
outside of local context Stale swizzled pointers can cause problems
86
Shared Memory in a Wide Virtual Address Space When virtual memory was created, 16 or 32
bit addresses were available Reasonable size for one process
But maybe not for all processes on a machine And certainly not for all processes ever on a
machine
87
Wide Address Space Architectures
Computer architects can now give us 64-bit virtual addresses
A 64-bit address space, consumed at 100 MB/sec, lasts 5000 years Orders of magnitude beyond any process’s
needs 40 bits can address a TB
88
Do we care?
Should OS designers care about wide address space?
Well, what can we do with them? One possible answer:
Put all processes in the same address space Maybe all processes for all time?
89
Implications of Single Shared Address Space IPC is trivial
Shared memory, RPC Separation of concepts of address space and
protection domain Uniform address space
90
Address Space and Protection Domain A process has a protection domain
The data that cannot be touched by other processes
And an address space The addresses it can generate and access
In standard systems, these concepts are merged
91
Separating the Concepts
These concepts are potentially orthogonal Just because you can issue an address
doesn’t mean you can access it (Though clearly to access an address you
must be able to issue it) Existing hardware can support this separation
92
Context-Independent Addressing
Addresses mean the same thing in any execution context
So, a given address always refers to the same piece of data
Key concept of uniform-address systems Allows many OS optimizations/improvements
93
Uniform-Addressing Allows Easy Sharing Any process can issue any address
So any data can be shared All that’s required is changing protection to
permit desired sharing Suggests programming methods that make
wider use of sharing
94
To Opal System
New OS using uniform-addressing Developed at University of Washington Not intended as slight alteration to existing
UNIX system Most of the rest of material specific to Opal
95
Protection Mechanisms for Uniform-Addressing Protection domains are assigned portions of
the address space They can allow other protection domains to
access them Read-only Transferable access permissions System-enforced page-level locking
96
Program Execution in Uniform-Access Memory Executing a program creates a new
protection domain The new domain is assigned an unused
portion of the address space But it may also get access to used portions E.g., a segment containing the required
executable image
97
Virtual Segments
Global address space is divided into segments Each composed of variable number of
contiguous virtual pages Domains can only access segments they
attach to Attempting to access unattached segment
causes a segment fault
98
Persistent Memory in Opal
Persistent segments exist even when attached to no current domain
Recoverable segments are permanently stored And can thus survive crashes
All Opal segments can be persistent and recoverable
Pointers can thus live forever on disk
99
Code Modules in Opal
Executable code stored in modules Independent of protection domains
Pure modules can be easily shared Because they are essentially static
Can get benefit of dynamic loading without run-time linking
100
Address Space Reclamation
Trivial in non-uniform-address systems Tricky in uniform-address systems Problem akin to reclaiming i_nodes in the
presence of hard links But even if segments improperly reclaimed,
only trusting domains can be hurt
101
Windows NT IPC
Inter-thread communications Within a single process
Local procedure calls Between processes on same machine
Shared memory
102
Windows NT and Threads
Windows NT support multiple threads of control in a single process address space
Threads share address space So communication among them is through
memory
103
Windows NT and Client/Server Computing Windows NT strongly supports the
client/server model of computing Various OS services are built as servers,
rather than part of the kernel Windows NT needs facilities to support
client/server operations Which guide users to building client/server
solution
104
Client/Server Computing and RPC
In client/server computing, clients request services from servers
Service can be requested in many ways But RPC is a typical way
Windows NT uses a specialized service for single machine RPC
105
Local Procedure Call (LPC)
Similar in many ways to RPC But optimized to only work on a single
machine Primarily used to communicate with protected
subsystems Windows NT also provides a true RPC facility
for genuinely distributed computing
106
Basic Flow of Control in Windows NT LPC Application calls routine in an application
programming interface Which is usually in a dynamically linked
library Which sends a message to the server
through a messaging mechanism
107
Windows NT LPC Messaging Mechanisms Messages between port objects Message pointers into shared memory Using dedicated shared memory segments
108
Port Objects
Windows NT is generally object-oriented Port objects support communications Two types:
Connection ports Communication ports
109
Connection Ports
Used to establish connections between clients and servers
Named, so they can be located Only used to set up communication ports
110
Communication Ports
Used to actually pass data Created in pairs, between given client and
given server Private to those two processes Destroyed when communications end
111
Windows NT Port Example
Client process Server process
Connection port
112
Windows NT Port Example
Client process Server process
Connection port
113
Communication ports
Windows NT Port Example
Client process Server process
Connection port
114
Communication ports
Windows NT Port Example
Client process Server process
Connection port
Send request
115
Message Passing through Port Object Message Queues One of three methods in Windows NT to pass
messages1. Client submits message to OS
2. OS copies to receiver’s queue
3. Receiver copies from queue to its own address space
116
Characteristics of Message Passing via Queues Two message copies required Fixed-sized, fairly short message
~256 bytes Port objects stored in system memory
So always accessible to OS Fixed number of entries in message queue
117
Message Passing Through Shared Memory Used for messages larger than 256 bytes Client must create section object
Shared memory segment Of arbitrary size
Message goes into the section Pointer to message sent to receiver’s queue
118
Setting up Section Objects
Pre-arranged through OS calls Using virtual memory to map segment into
both sender and receiver’s address space If replies are large, need another segment for
the receiver to store responses OS doesn’t format section objects
119
Characteristics of Message Passing via Shared Memory Capable of handling arbitrarily large transfers Sender and receiver can share a single copy
of data i.e., data copied only once
Requires pre-arrangement for section object
120
Server Handling of Requests
Windows NT servers expect requests from multiple clients
Typically, they have multiple threads to handle requests
Must be sufficiently general to handle many different ports and section objects
121
Message Passing Through Quick LPC Third way to pass messages in Windows NT Used exclusively with Win32 subsystem Like shared memory, but with a key difference
Dedicated resources
122
Use of Dedicated Resources in Quick LPC To avoid overhead of copying
Notification messages to port queue And thread switching overhead
Client sets up dedicated server thread only for its use
Also dedicated 64KB section object And event pair object for synchronization
123
Characteristics of Message Passing via Quick LPC Transfers of limited size Very quick Minimal copying of anything Wasteful of OS resources
124
Shared Memory in Windows NT
Similar in most ways to other shared memory services
Windows NT runs on multiprocessors, which complicates things
Done through virtual memory
125
Shared Memory Sections
Block of memory shared by two or more processes Created with unique name
Can be very, very large
126
Section Views
Given process might not want to waste lots of its address space on big sections
So a process can have a view into a shared memory section
Different processes can have different views of same section
Or multiple views for single process
127
Shared Memory View Diagram
Process A Process B
Physical memory
Section
view 1 view 2
view 3
128