Inter-Process Communication: Message Passing
Inter-Process Communication: Message Passing
Inter-Process Communication: Message Passing
•Fixed-length messages:
–simple to implement - can have pool of standard-sized buffers
»low overheads and efficient for small lengths
copying overheads if fixed length too long
–can be inconvenient for user processes with variable amount of data to
pass
»may need a sequence of messages to pass all the data
»long messages may be better passed another way e.g. FTP
copying probably involved, sometimes multiple copying into kernel and out
•Variable-length messages:
–more difficult to implement - may need a heap with garbage collection
»more overheads and less efficient, memory fragmentation
–more convenient for user processes
2
Operating Systems: IPC
3
Operating Systems: IPC
•Asymmetric addressing:
–only the sender names the recipient
–recipient not required to name the sender - need not know the sender
send ( P, message ) : send message to process P
receive ( id, message ) : receive from any process, id set to sender
•Disadvantage of direct communications :
–limited modularity - changing the name of a process means changing every
sender and receiver process to match
–need to know process names
•Indirect communications :
–messages sent to and received from mailboxes (or ports)
»mailboxes can be viewed as objects into which messages placed by
processes and from which messages can be removed by other processes
–each mailbox has a unique ID
–two processes can communicate only if they have a shared mailbox
5
Operating Systems: IPC
6
Operating Systems: IPC
•many-to-many :
–e.g. multiple senders requesting service and a pool of receiving servers offering
service - a server farm
•Mailbox Ownership
–process mailbox ownership :
»only the process may receive messages from the mailbox
»other processes may send to the mailbox
»mailbox can be created with the process and destroyed when the process dies
process sending to a dead process’s mailbox will need to be signalled
»or through separate create_mailbox and destroy_mailbox calls
possibly declare variables of type ‘mailbox’
–system mailbox ownership :
»mailboxes have their own independent existence, not attached to any process
»dynamic connection to a mailbox by processes
for send and/or receive
7
Operating Systems: IPC
8
Operating Systems: IPC
10
Operating Systems: IPC
•Asynchronous :
–send and receive operations non-blocking
»sender continues when no corresponding receive outstanding
»receiver continues when no message has been sent
–properties :
»messages need to be buffered until they are received
amount
of buffer space to allocate can be problematic
a process running amok could clog the system with messages if not careful
»often very convenient rather than be forced to wait
particularly for senders
»can increase concurrency
»some awkward kernel decisions avoided
e.g.
whether to swap a waiting process out to disc or not
–receivers can poll for messages
»i.e. do a test-receive every so often to see if any messages waiting
»interrupt and signal programming more difficult
»preferable alternative perhaps to have a blocking receive in a separate thread
11
Operating Systems: IPC
•Other combinations :
–non-blocking send + blocking receive
»probably the most useful combination
»sending process can send off several successive messages to one or more
processes if need be without being held up
»receivers wait until something to do i.e. take some action on message
receipt
a server process
e.g.
might
wait on a read until a service request arrived,
transfer the execution of the request to a separate thread
then
then
go back and wait on the read for the next request
–blocking send + non-blocking receive
»conceivable but probably not a useful combination
–in practice, sending and receiving processes will each choose independently
•Linux file access normally blocking :
–to set a device to non-blocking (already opened with a descriptor fd) :
fcntl ( fd, F_SETFL, fcntl ( fd, F_GETFL) | O_NDELAY )
12
Operating Systems: IPC
•Missing messages ?
–message sent but never received
»receiver crashed?
»receiver no longer trying to read messages?
–waiting receiver never receives a message
»sender crashed?
»no longer sending messages?
•Crashing processes :
–kernel knows when processes crash
–can notify waiting process
»by synthesised message
»by signal
»terminate process
13
Operating Systems: IPC
•Time-outs
–add a time-limit argument to receive
receive ( mailbox, message, time-limit )
–if no message received by time-limit after issuing the receive:
»kernel can generate an artificial synthesised message saying time-out
»could signal receiver process with a program-error
allows
receiver to escape from current program context
–sending process can also be protected using a handshake protocol :
–sender :
send (mailbox, message)
receive (ackmail, ackmess, time-limit)
–receiver :
receive (mailbox, message, time-limit)
if ( message received in time ) send (ackmail, ackmess)
14
Operating Systems: IPC
•Lost messages
–particularly relevant in distributed systems
–OS’s need to be resilient i.e. not crash either the kernel or user processes
–options:
»kernel responsible for detecting message loss and resending
to buffer message until receipt confirmed
need
can
assume unreliability and demand receipt confirmation within a time limit
»sending process responsible for detecting loss
receipt
confirmation within time-limit and optional retransmit
»kernel responsible for detecting loss but just notifies sender
sender
can retransmit if desired
–long transmission delays can cause problems
»something delayed a message beyond its time limit but still in transit
if message retransmitted, multiple messages flying about
to identify messages e.g. serial numbers, and discard any duplicates
need
»scrambled message - checksums etc.
»see Communications module!
15
Operating Systems: IPC
–producer :
»get a message block from mayproduce
»put data item in block
»send message to mayconsume
–consumer :
»get a message from mayconsume
»consume data in block
»return empty message block to mayproduce mailbox
18
Operating Systems: IPC
–properties :
»no shared global data accessed
»all variables local to each process
»works on a distributed network in principle
»producers and consumers can be heterogeneous
written in different programming languages - just need library support
run
on different machine architectures - ditto
20
Operating Systems: IPC
21
Operating Systems: IPC
23
Operating Systems: IPC
#include <unistd.h>
#include <stdio.h>
main() {
int fda[2]; // file descriptors [0] : read end, [1] write end
char buf[1]; // data buffer
file descriptors open file descriptors file descriptors open file descriptors
0 0
1 1
2 2
3 3
26
Operating Systems: IPC
#include <unistd.h>
#include <stdio.h>
main() {
int fda[2]; // file descriptors
27
Operating Systems: IPC
#include <stdio.h>
#include <sys/stat.h>
#include <fcntl.h>
#define WRFLAGS (O_WRONLY | O_CREAT | O_TRUNC)
#define MODE600 (S_IRUSR | S_IWUSR)
main() {
close (0); // close standard input
if (open(“file1”, O_RDONLY) == -1) error(“open input file failed\n”);
•Sockets
–intended for communications across a distributed network
–uses the connectionless Internet Protocol and IP addresses at the lowest
level e.g. 129.215.58.7
–datagram packets transmitted to destination IP host
–User Datagram Protocol (UDP) or Transmission Control Protocol (TCP) at
the application level
–TCP is a connection based protocol, with order of packet arrival guaranteed
–a socket is a communication end-point
–once a TCP-socket connection between two processes is made, end-points
made to act like ordinary files, using read() and write() system calls.
30
Operating Systems: IPC
–a Client-Server system :
»creating a socket :
sd = socket ( family, type, protocol );
»binding to a local address :
( sd, IP address, addrlen );// address includes port number connection by
bind
client process :
connect ( sd, IP address, addrlen ); // servers IP address
»server listens for client connection requests :
listen
( sd, queuelen ); // number of requests that can be queued
»and accepts the request :
newsd = accept ( sd, IP address, addrlen );
–accept() normally blocks if no client process waiting to establish a
connection
–can be made non-blocking for server to enquire whether any clients waiting
–connectionless communication with UDP datagram sockets also possible
using sendto() and recvfrom() system calls
31
Operating Systems: IPC
#include <fcntl.h>
#include <linux/socket.h>
#include <linux/in.h>
#include <errno.h>
void main() {
int ssd, csd;
struct sockaddr_in server, client;
int sockaddrlen, clientlen, ca;
char message[MESSAGELEN];
int messagelen;
32
Operating Systems: IPC
// create socket
if ((ssd = socket (AF_NET, SOCK_STREAM, 0)) < 0) {
printf(“socket create failed: %s\n”, strerror(errno));
exit(1):
} else printf(server socket created, ssd = %d\n”, ssd);
// bind socket to me
server.sin_family = AF_INET;
server.sin_port = htons(SERVER_PORT); // big/little-endian conversion
server.sin_addr.s_addr = htonl(SERVER);
bzero(&server.sin_zero, 8);
if (bind(ssd, (struct sockaddr *) &server, sockaddrlen) < 0) {
printf(“server bind failed: %s\n”, strerror(errno));
exit(1):
}
33
Operating Systems: IPC
ca = ntohl(client.sin_addr.s_addr);
printf(“client accepted, csd = %d, IP = %d.%d.%d.%d\n”,
csd, (ca>>24)&255, (ca>>16)&255, (ca>>8)&255, ca&255);
34
Operating Systems: IPC
close_socket(ssd);
35
Operating Systems: IPC
void main() {
int ssd, csd;
struct sockaddr_in server, client;
int sockaddrlen, clientlen, ca;
char message[MESSAGELEN];
int messagelen;
36
Operating Systems: IPC
// server address
server.sin_family = AF_INET;
server.sin_port = htons(SERVER_PORT);
server.sin_addr.s_addr = htonl(SERVER);
for (;;) {
//create socket
if ((csd = socket(AF_INET, SOCK_STREAM, 0)) < 0) {
printf(“client socket create failed: %s\n”, strerror(errno));
exit(1);
} else prinf(“client socket create, csd = %d\n”, csd);
37
Operating Systems: IPC
close_socket(csd);
38
Operating Systems: IPC
•Signals
–the mechanism whereby processes are made aware of events occurring
–asynchronous - can be received by a process at any time in its execution
–examples of Linux signal types:
»SIGINT: interrupt from keyboard
»SIGFPE: floating point exception
»SIGKILL : terminate receiving process
»SIGCHLD : child process stopped or terminated
»SIGSEGV : segment access violation
–default action is usually for kernel to terminate the receiving process
–process can request some other action
»ignore the signal - process will not know it happened
SIGKILL
and SIGSTOP cannot be ignored
»restore signal’s default action
»execute a pre-arranged signal-handling function
process
can register a function to be called
like
an interrupt service routine
39
Operating Systems: IPC
the handler returns, control is passed back to the main process code and
when
normal execution continues
40
Operating Systems: IPC
#include <stdio.h>
#include <signal.h>
#include <unistd.h>
int ctrl_C_count = 0;
void (* old_handler)(int);
void ctrl_c(int);
main () {
int c;
old_handler = signal (SIGINT, ctrl_c );
for (;;);
}
•see also the POSIX sigaction() call - more complex but better
41