1.

Introduction
Interprocess communication (IPC) refers to the coordination of activities among cooperating
processes. A common example of this need is managing access to a given system resource. To
carry out IPC, some form of active or passive communication is required.
The increasingly important role that distributed systems play in modern computing environments
exacerbates the need for IPC. Systems for managing communication and synchronization between
cooperating processes are essential to many modern software systems. IPC has always played a
prominent role in UNIX-variant operating systems, but it has been largely overlooked for systems
running the Windows NT operating system. This paper will discuss some of the IPC options that
are available to programmers using UNIX and describe the corresponding techniques available to
programmers writing for Windows NT. Features and mechanisms specific to Windows NT will
also be discussed. The conclusion will offer a summary of the available techniques as applicable to
Windows NT.

2. Pipes
Pipes are a simple synchronized way of passing information between two processes. A pipe can be
viewed as a special file that can store only a limited amount of data and uses a FIFO access
scheme to retrieve data. In a logical view of a pipe, data is written to one end and read from the
other. The processes on the ends of a pipe have no easy way to identify what process is on the
other end of the pipe.
The system provides synchronization between the reading and writing process. It also solves the
producer/consumer problem: writing to a full pipe automatically blocks, as does reading from an
empty pipe. The system also assures that there are processes on both ends of the pipe at all time.
The programmer is still responsible, however, for preventing deadlock between processes.
Pipes come in two varieties:
Unnamed. Unnamed pipes can only be used by related processes (i.e. a process and one of its
child processes, or two of its children). Unnamed pipes cease to exist after the processes are
done using them.
Named. Named pipes exist as directory entries, complete with permissions. This means that
they are persistent and that unrelated processes can use them.

2.1 UNIX
Most UNIX systems limit pipes to 5120K (typically ten 512K chunks). The unbuffered system call
write() is used to add data to a pipe. Write() takes a file descriptor (which can refer to the pipe), a
buffer containing the data to be written, and the size of the buffer as parameters. The system
assures that no interleaving will occur between writes, even if the pipeline fills temporarily. To get
data from a pipe, the read() system call is used. Read() functions on pipes much the same as it
functions on files. However, seeking is not supported and it will block until there is data to be
read.
The pipe() system call is used to create unnamed pipes in UNIX. This call returns two pipes. Both
support bidirectional communication (two pipes are returned for historical reasons: at one time
pipes were unidirectional so two pipes were needed for bidirectional communication). In a fullduplex environment (i.e. one that supports bidirectional pipes) each process reads from one pipe

and writes to the other; in a half-duplex (i.e. unidirectional) setting, the first file descriptor is
always used for reading and the second for writing.
Pipes are commonly used on the UNIX command line to send the output of one process to another
process as input. When a pipe is used both processes run concurrently and there is no guarantee as
to the sequence in which each process will be allowed to run. However, since the system manages
the producer/consumer issue, both proceed per usual, and the system provides automatic blocking
as required.
Using unnamed pipes in a UNIX environment normally involves several steps:
Create the pipe(s) needed
Generate the child process(es)
Close/duplicate the file descriptors to associate the ends of the pipe
Close the unused end(s) of the pipe(s)
Perform the communication
Close the remaining file descriptors
Wait for the child process to terminate
To simplify this process, UNIX provides two system calls that handle this procedure. The call
popen() returns a pointer to a file after accepting a shell command to be executed as input. Also
given as input is a type flag that determines how the returned file descriptor will be used. The
popen() call automatically generates a child process, which exec()s a shell and runs the indicated
command. Depending on the flag passed in, this command could have either read or write access
to the file. The pclose() call is used to close the data stream opened with popen(). It takes the file
descriptor returned by popen() as its only parameter.
Named pipes can be created on the UNIX command line using mknod, but it is more interesting to
look at how they can be used programatically. The mknod() system call, usable only by the
superuser, takes a path, access permissions, and a device (typically unused) as parameters and
creates a pipe referred to by the user-specified path. Often, mkfifo() will be provided as an
additional call that can be used by all users but is only capable of making FIFO pipes.

2.2 Windows NT
Windows NT supports both named and unnamed pipes, although it refers to the latter as
anonymous pipes.
The CreatePipe() function creates an anonymous pipe and returns two handles. One handle is a
read handle to the pipe and the other is a write handle to the pipe; neither pipe can perform the
opposite operation. When the pipe is created the server requests that it be implemented using a
programmer-defined buffer size. To communicate using the pipe, the server must pass one of the
handles to another process. Usually, this is done through inheritance; that is, the process allows the
handle to be inherited by a child process. The process can also send the handle to an unrelated
process using another form of interprocess communication, such as shared memory.
A server can send either the read handle or the write handle to the pipe client, depending on
whether the client should use the anonymous pipe to send information or receive information. To
read from the pipe, the pipe's read handle is used as a parameter to the call ReadFile(). The
ReadFile() call returns when another process has written to the pipe. ReadFile() call can also
return if all write handles to the pipe have been closed or if an error occurs before the read
operation has been completed.

3. Sockets
A socket is a software abstraction that is used to create a channel-like interface between processes.
The channel allows bi-directional communication between processes, but does little to structure
the data being transmitted. In general, the serving machine in a system that uses socket
communication follows several steps to initiate communication:
Create a socket
Map the socket to a local address
Listen for client requests
When the client process wishes to begin a transaction with the server, it follows similar steps:
Create a socket
Determine the location (system name and port number) of the server
Begin sending and/or receiving data

3.1 Types of Sockets

Communication between processes via sockets can be viewed as streams or datagrams. Streambased communication views transmitted data as a sequence of bytes, whereas datagram-based
communication deals with small discrete packets of information. These packets typically contain
header and trailer information in addition to the data being transmitted. Choosing a socket type is
important, because each has different performance and reliability characteristics, and two
communicating sockets must be of the same type.
Stream. Stream sockets are reliable; that is, data is guaranteed to be delivered in the same
order it was sent. An underlying mechanism that the programmer need not be concerned with
handles duplicate data, performs error checking, and controls flow. When using stream
sockets, a connection is established. This means that two processes must logically agree to
communicate before information can be transferred between the two of them. This connection
is maintained by both processes throughout the communication session.
Datagram. Datagram sockets provide unreliable communication between the two processes,
meaning that data could be received out of order. Datagram sockets provide no notion of a
connection, so each datagram is sent and processed independently. This has a host of
implications, one of the most significant of which is that individual datagrams can take
different paths to their ultimate destination. Another important implication is that there is no
flow control. Datagram packets are typically quite small and usually are fixed in size. No
error correction is mandated, and when optional error connection is used, it is weak.

3.2 Berkeley Sockets

In the early 1980s, the Berkeley socket interface was introduced and it has formed the basis for
UNIX sockets programming ever since. Berkeley sockets allow general file system type access
routines to be used to send and receive information over a network connection. Berkeley sockets
are completely protocol independent, so they need not use TCP/IP for communication although
this is most common.
Berkeley sockets support asynchronous I/O, meaning that the process can request that the kernel
alert it when a specified socket descriptor is ready for I/O. In most UNIX implementations, the
notification from the kernel to the user process occurs via the SIGIO signal. Because a given
process can have only a single signal handler for each signal, to use asynchronous I/O with more
than one socket, another technique is used. Otherwise, the process would not know which socket
is ready for I/O. Such multiplexing is implemented via the select() system call.

ports. Finally, these classes still rely on WinSock v1.1; they do not take advantage of the new
features or enhanced efficiency of WinSock v2.2 yet.

4. Shared Memory
Shared memory allows multiple processes to share virtual memory space so changes made by one
process are instantly reflected in other processes. This affords the fastest possible IPC but is not
necessarily the easiest to coordinate between the two processes. Shared memory is unique in that it
allows random access of data, whereas most other IPC mechanisms mandate sequential access to
data. Typically, one process creates a shared segment, and needs to set access permissions for the
segment. It is then mapped into the processs address space after the process attaches to it. Usually
the creating process initializes the memory, but after this other processes that have been given
access permission to the segment can use it freely. When another process does use it, it is mapped
into its address space. Oftentimes semaphores are used by the original process to be sure that only
one other process is allowed to access the memory at any one time, although a readers/writers lock
may be a more suitable solution. When no process needs the memory segment anymore, the
creating process can delete it.

4.1 Creating a Shared Memory Segment

When programming for UNIX, a new shared memory segment can be created using the shmget()
call. Using shmget() also generates the required data structures. If a shared memory segment was
created by another process previously, using shmget() allows a process to gain access to the
existing segment since shared memory segments are identified by unique identifiers returned by
the call. When creating a new segment, the programmer can specify a key to associate with an
existing shared memory segment, the size of the segment requested, and the creation and access
conditions. Note that creating a shared segment only reserves space for it; the process still cannot
access it.
Using a shared memory region under Windows NT requires two distinct steps, much as it does in
UNIX: creating a kernel object specifying the size of the shared area and then mapping this filemapping object into the processs address space.
To carry out the first step the CreateFileMapping() call is used. This call usually allows a file to be
accessed as if in memory (not unlike the UNIX mmap() call) but can be used to create a place in
one of the system paging files. This place, once reserved, can be accessed by name via the kernel.
When using CreateFileMapping in this way, the file handle passed in is a special constant
representing that a paging file should be used. Other parameters that CreateFileMapping() takes
include flags for security attributes, access specifiers (which are normally set to allow page read
and write access when using shared memory), the size of the segment to be mapped, and name that
the segment can be referred to as. If the call returns successfully, a handle to a file-mapping kernel
object is available to the calling process. It is not necessary to use the paging file for the mapping;
however, doing so prevents processes from needing to agree on using a common file name and
eliminates the possibility of having temporary files to cleanup. The choice of whether or not to use
a pagefile or some other file effectively allows Windows NT to mimic both types of mapping
possible under UNIX.3 However, UNIX simplifies the case of general (not file mapped) shared
memory by completely removing the burden of dealing with files.

Windows NT requires the decision to be made earlier in the process, however; the second type of
mapping has not yet been presented.

13

4.2 Controlling a Shared Memory Segment

Once a UNIX process has created a shared memory segment, it can control it using the shmctl()
system call. This call can potentially affect existing shared memory segments as well as the
system-maitained shared memory control structures. The call takes a key representing a previously
created segment, a command (specified via a constant), and a buffer containing a struct that
effectively serves as the parameters for the specified command. Possible commands include:
IPC_STAT: returns the values of the associated data structure to a process having read access
to the segment
IPC_SET: allows a process with an effective UID of superuser or the UID of the process used
to create the segment to modify the segments associated user and group identifiers, as well as
change the access permissions
IPC_RMID: remove the system data structure, effectively indicating that the process is done
with the shared segment and that if no other process is still using it then it can be deleted
SHM_LOCK: allows the superuser to lock a shared segment in memory
SHM_UNLOCK: allows the superuser to unlock a shared segment locked into memory
Windows NT does not offer similar features to user-level processes. This higher degree of
management by the kernel is useful at times but does place some limits on the flexibility of shared
memory for Windows NT.

4.3 Shared Memory Operations

UNIX features two operations to work with shared memory: shmat() and shmdt(). These allow
processes to attach and detach from shared memory segments, respectively.
When a process attached to a shared memory segment using shmat(), the referenced shared
memory is mapped into the calling processs data segment. The call takes an identifier of an
existing shared memory segment, a flag that specifies the access permissions for the shared
segment and to request special conditions (such as address alignment), and a suggestion for
placement of the segment. This last argument is passed in as a void*, which is usually set to null,
indicating that the system should choose the addresses that it feels best. However, the process
could pass in a suggested address. The memory is then mapped into the nearest available page
address.
When a process wishes to detach from a segment, it can use the shmdt() system call. The call takes
only a reference to an attached memory segment.
When programming for UNIX, programmers can use the mmap() system call to map a file into a
processs virtual address space. Mapping files has several advantages over using traditional shared
memory segments. In particular, standard system calls can be used to manipulate the memory as
desired (instead of the specialized calls that shared memory segments require) and files are
persistent. The mmap() call takes several parameters. It accepts a user-specified address to try to
map the file into, much as the shmat() call does. In addition, the length of the mapped memory
area can be specified along with the access privileges that should apply. Various flags can be used
to set attributes for the mapping, such as whether the map should be shared or private, whether the
address needs to be fixed, and whether or not swap space should be reserved for the mapping.
Although the file will be unmapped when the process terminates, the process can unmap it at any
time using munmap(), which accepts the address and size of the memory block as parameters.
Windows NT provides equivalent functionality through the use of the OpenFileMapping() and
UnmapViewOfFile() system calls.

14

The OpenFileMapping() call returns a handle to a file-mapping kernel object that was previously
created using CreateFileMapping(). As parameters it takes the level of access that is desired for the
segment, whether or not child processes should inherit the handle, and the name of the memory
region to open (as specified when CreateFileMapping() was called). After the handle to the kernel
object is acquired, a pointer to the memory that it represents is required. The MapViewOfFile()
call can be used to get this pointer. MapViewOfFile() takes the handle returned by
CreateFileMapping(), the desired level of access to the memory, and the size of the region to map
as parameters. It returns a pointer to the beginning of the memory segment.
When the shared map is no longer required, it should be released using UnmapViewOfFile(). It
takes the address of the memory (as returned by MapViewOfFile()) as a parameter. The
programmer should also be careful to close the handle to the file-mapping kernel object.

5. Mailslots
Mailslots, available only in Windows NT, provide one-way communication between processes. A
mailslot is a pseudofile; it resides in memory, and standard file functions are used to access it. The
data in a mailslot message can be in any form. When all handles to a mailslot are closed, the
mailslot and all the data it contains are deleted, so mailslots cannot be used for long-term storage.
A mailslot server is a process that creates and owns a mailslot. When the server creates a mailslot,
it receives a mailslot handle. This handle must be used when a process reads messages from the
mailslot. Only the process that creates a mailslot or obtains a handle to can read from the mailslot.
All mailslots are local to the process that creates them; a process cannot create a remote mailslot.
A mailslot client is a process that writes a message to a mailslot. Any process that has the name of
a mailslot can put a message there. New messages follow any existing messages in the mailslot.
Processes that create mailslots act as servers to other processes that send messages to it by writing
a message to its mailslot. Incoming messages are always appended to the mailslot and are saved
until the mailslot server has read them. A process can be both a mailslot server and a mailslot
client, so two-way communication is possible using multiple mailslots. This is useful for
implementing a simple message-passing facility within a domain
Mailslot clients can send a message to any number of mailslot servers located anywhere on the
network with a single call, as long as the mailslots all share the same name. The message can also
be restricted to the local machine or a specific machine on the network. Messages broadcast to all
mailslots on a domain can be no longer than 400 bytes, whereas messages sent to a single mailslot
are limited only by the maximum message size specified by the mailslot server when it created the
mailslot.

6. Conclusions
6.1 Review
Both UNIX and Windows NT provide efficient pipe implementations that are excellent in their
own unique ways. The UNIX implementation is very simple to use whereas the Windows NT
implementation is quite complex (in comparison), but affords the programmer substantially more
flexibility. The abundance of information available at runtime allows powerful servers handling
multiple clients to be created. The possibility for pipes to alternate between being synchronous and
asynchronous is also a nice feature. Windows NT also natively supports multiple pipes, does not
restrict the use of unnamed pipes to related processes, and allows bi-directional communication
using a single pipe. Under both operating systems, pipes provide a reliable means for IPC, and the
two parties can verify receipt of data in real-time.

15