Windows Pipes and Mailslots

In this article:

Anonymous Pipes.

Named Pipes.

Mailslots.

Pipes:

Two primary Windows mechanisms for IPC are the anonymous pipe and the named pipe, both of which are accessed with the familiar WriteFile and ReadFIle functions. Simple anonymous pipes are character-based and half-duplex. As such, they are well suited for redirecting the output of one program to the input of another, as is common with communicating Linux and UNIX programs.

Named pipes are much more powerful than anonymous pipes. They are fullduplex and message-oriented, and they allow networked communication. Furthermore, there can be multiple open handles on the same pipe. These capabilities, coupled with convenient transaction-oriented named pipe functions, make named pipes appropriate for creating client/server systems.

Mailslots, which allow for one-to-many message broadcasting and are also filelike, are used to help clients locate servers.

Anonymous Pipes are useful for simple byte-based communication programs inside the within the same machine. Whereas Named Pipes have the following features:

Named pipes are message-oriented, so the reading process can read varyinglength messages precisely as sent by the writing process

Named pipes are bidirectional, so two processes can exchange messages over the same pipe.

There can be multiple, independent instances of pipes with the same name. For example, several clients can communicate concurrently with a single server using distinct instances of a named pipe. Each client can have its own named pipe instance, and the server can respond to a client using the same instance.

Networked clients can access the pipe by name. Named pipe communication is the same whether the two processes are on the same machine or on different machines.

Several convenience and connection functions simplify named pipe request/ response interaction and client/server connection.

Figure above shows an illustrative client/server relationship, and the pseudocode shows one scheme for using named pipes. Notice that the server creates multiple instances of the same pipe, each of which can support a client. The server also creates a thread for each named pipe instance, so that each client has a dedicated thread and named pipe instance.

When creating a named pipe, the name must be in the form “\\.\pipe\pipename” the period (.) stands for the local machine; thus, you can’t create a pipe on a remote machine. The pipename is case-insensitive, can be up to 256 characters long, and can contain any character other than backslash.

When client is about initializing an instance from a named pipe:

If the server on the same machine use: “\\.\pipe\pipename”

If the server on remote machine use: “\\servername\pipe\pipename”

 

Mailslots:

A Windows mailslot, like a named pipe, has a name that unrelated processes can use for communication. Mailslots are a broadcast mechanism, similar to datagrams, and behave differently from named pipes, making them useful in some important but limited situations. Here are the significant mailslot characteristics:

A mailslot is one-directional

A mailslot can have multiple writers and multiple readers, but frequently it will be one-to-many of one form or the other

A writer (client) does not know for certain that all, some, or any readers (servers) actually received the message

Mailslots can be located over a network domain

Message lengths are limited

Last but not least, client can locate mailslot performing CreateFile using the name “\\*\mailslot\mailslotname“. In this way, the * acts as wildcard and the client can locate every server on the domain, a networked group of systems assigned a common name by the network administrator.

These tables summarize pipes and mailslots

Windows pipes and mailslots, which are accessed with file I/O operations, provide stream-oriented interprocess and networked communication.

Structured Exception Handling

C++, C#, and other languages have very similar mechanisms, however, and these mechanisms build on the SEH facilities presented here.

Console control handlers, allow a program to detect external signals such as Ctrl-C a from the console or the user logging off or shutting down the system. These signals also provide a limited form of process-to-process signaling.

Vectored exception handling allows the user to specify functions to be executed directly when an exception occurs, and the functions are executed before SEH is invoked.

Exception handlers can respond to a variety of asynchronous events, but they do not detect situations such as the user logging off or entering a Ctrl-C from the keyboard to stop a program. Use console control handlers to detect such events.

There is important distinction between exceptions and signals. A signal applies to the entire process, whereas an exception applies only to the thread executing the code where the exception occurs.

Exception handling functions can be directly associated with exceptions, just as console control handlers can be associated with console control events. When an exception occurs, the vectored exception handlers are called first, before the system unwinds the stack to look for structured exception handlers.

Console control handlers can respond to external events that do not generate exceptions. VEH is a newer feature that allows functions to be executed before SEH processing occurs. VEH is similar to conventional interrupt handling.