Lecture 5 - Interprocess Communication

IPC Across Computers: RPC Implementation

- Common Object Request Broker Architecture (CORBA). - Java Remote Message Invocation (RMI). see next week's lab - SOAP (formerly Simple Object Access Protocol ) Web services. - Windows Communication Foundation (WCF)

IPC Across Computers: Why RPC?

- Extends the conventional procedure call to the client/server model. - Remote procedures accept arguments and return results. - Makes it easy to design and understand programs. - Helps programmer to focus on the application instead of the communication protocol. - Allows a client to execute procedures on other computers - Simplifies the task of writing client/server programs. RPC forms the foundation for many distributed utilities used today, like NFS and NIS in UNIX-based systems.

Advantages of process cooperation

- Information sharing - Computation speed-up (parallel processing) - Modularity

IPC Across Computers: Remote Procedure Call (RPC)

- Suggested by Birell and Nelson in 1984 Goals: Access-transparent call semantics. Remote calls look like local procedure calls. require to convert calls into network messages. Server: Exports modules of procedures (somehow) Clients: Call these procedures (somehow). Look as close as possible to local-procedure call, but really network messages.

Single System IPC: Traditional IPC: System V

- System V was a dialect of UNIX developed in the 1980s. - Many features adopted into POSIX standards, and still available today in LInux, etc. - It incorporated APIs for singe-system IPC supporting, for example: - Shared memory segments - Semaphres - Message queues

IPC Across Computers: Socket Scenario

1. Server creates socket (socket system call), binds it to an IP address and port (bind), and marks it as a server socket (listen) 2. Sever does accept, to wait for connection from client. 3. Client creates socket (socket)... 4. ... and connects to IP address and port for server socket (connect). 5. A new socket is created on server connected to client socket; hosts communicate. 6. Server may do accept again, waiting for other connections...

IPC Across Computers: Using Sockets

After initialising a socket by socket(), bind(), listen(), "server" waits for connections on specified port by calling accept(). "Client" calls connect(), passing in a local socket and address of server socket, (IP address plus port number). If connection succeeds, a new socket is returned by accept(). Client and server exchange byte arrays of data over the socket pair using send() and recv() calls.

Towards Common APIs

Application Programming Interface (API) is the generic name for an interface to some library of software functions We first review some "traditional" APIs for IPC - specifically applicable to the "single-system" case. But, has become increasingly common to adopt the more general "different-systems" APIs, even when the communicating processes happen to run on the same system In recent years much work has been put into developing these APIs for distributed systems.

IPC Across Computers: Socket API

Berkeley Sockets API implemented by systems calls in Linux or Windows:

Single System IPC: System V Shared Memory API

Creating shared memory segments in general done in systems languages like C, e.g.: (image) Creates and attaches to a shared memory segment of size 1024 bytes, identified by key.

IPC Across Computers: Message Passing: Implementations

For general messaging there is the Java Message Service (JMS) API, implemented by various projects and vendors, e.g.: Sun (Oracle) Java System Message Queue BEA Weblogic IBM WebSphere For parallel computing there is the Message Passing Interface (MPI), implemented by open source projects and hardware vendors.

How can processes communicate?

IPC mechanisms include: Shared memory (memory oriented). - Processes communicated with each other through shared variables in memory. Pipes and sockets (stream oriented). - Processes communicate in continuous streams of bytes sent over persistent connections. Message passing (message oriented). - Processes communicate by sending each other discrete chunks of data - messages. Remote procedure call (procedure oriented). - Processes communicate using procedure call

Single System IPC: Scenario

Most familiar use is in UNIX shell, e.g.: 1. Shell creates pipe with two ends (pipe system call) 2. Shell creates two child processes (fork system calls) 3. Child processes exec ls and more commands respectively. 4. They communicate through the inherited pipe.

What is Inter-process Communication?

OS-supported mechanisms by which processes running in the same computer cooperate

Single System IPC: Memory Mapped Files

On modern UNIX-like systems it is more common to implement shared memory segments by using the virtual memory system explicitly. A process can explicitly map a specified file into their memory space using the POSIX function mmap. If two or more processes map the same file, this effectively creates a shared memory region.

Single System IPC: Shared memory issues

Once we have shared memory, the same issues of data consistency arise as with threads - How to prevent processes getting in each other's way when performing critical updates? - How to make sure processes access shared data in some orderly patterns? The same kinds of solutions apply, and System V and POSIX provide semaphores that can be accessed from multiple processes.

Single System IPC: Traditional IPC: Pipes

One of the simplest forms of single-System IPC - Still ubiquitous in UNIX-like systems (e.g. Linux) A UNIX pipe has an input and an output. - A stream of bytes is written to the output; the same stream of bytes is read from the input. - The inputting process will block if there is no data currently in the pipe. A pipe is created by some parent process, then used to communicate between (typically) two child processes.

IPC Across Computers: Message passing Issues

Problem: how many messages should be buffered temporarily during communication? Solutions: zero capacity queues: 0 messages, Sender always waits for receiver (synchronization is called rendezvous). Sounds restrictive, but simplifies formal analysis of distributed programs (CSP, CCS, Pi Calculus, etc) Bounded capacity queues: finite length of n messages, Sender waits if link buffer is full (e.g. MPI). Unbounded capacity queues: infinite queue length, Sender never waits Message queue in week 4 appendix, for example

Single System IPC: Shared Memory

Processes (in contrast to threads) have private address spaces, and in general don't share memory. This is the general rule, but specific system calls can be used to create memory areas that can be accessed by multiple processes.

Processes generally have their own ________________________________, and don't have any ________________________ in common.

Processes generally have their own private address space, and don't have any program variables in common.

IPC Across Computers: IPC via Message Passing

Processes interact by sending and receiving messages - Similar to pipes, but messages are isolated data chunks of specified size, rather than unstructured streams of bytes, as in pipes. - Sometimes say message passing is connectionless. As with pipes, problems of interference that arise when accessing shared data are avoided, and the model works for communications between processes on different computers.

Single System IPC: Traditional IPC: Shared Files

Require file locking or record locking to allow cooperating processes to share a resource safely - File - locks the whole file; - Record - locks portion of a file.

IPC Across Computers: Sockets

Sockets provide a programming model with some features of message passing, though they are mostly commonly used for stream-oriented communication. In this respect they are similar to pipes. But unlike pipes, sockets can connect unrelated processes - including processes on different computer.

IPC Across Computers: RPC issues

Transparency: - Syntactic transparency: RPC should have same syntax as local procedure call. - Semantic transparency: RPC semantics should be identical to local procedure call. Standard representation: Need for external data representation (XDR) for all data types. - One machine may be little-endian and the other machine may be big-endian. - One machine may be using ASCII and the other UTF-16 - Representation of floating point number on the two machines may be different.

Single System IPC: Stream-based IPC Using Pipes

Write and read like a file, but more efficient. - One way byte stream. - Kernel buffers the data. - Operates as a bounded buffer with blocking (buffer is 64kb in Linux).