Interprocess Communication

Agenda Anonymous pipes Anonymous pipes Named pipes Named pipes ConnectNamedPipe ConnectNamedPipe Mailslots Mailslots

IPC So far, however, we have not been able to perform direct process-to-process communication other than through shared memory. So far, however, we have not been able to perform direct process-to-process communication other than through shared memory. The next step is to provide sequential interprocess communication (IPC) between processes using filelike objects. Two primary Windows mechanisms for IPC are the anonymous pipe and the named pipe, both of which can be accessed with the familiar ReadFile and WriteFile functions. The next step is to provide sequential interprocess communication (IPC) between processes using filelike objects. Two primary Windows mechanisms for IPC are the anonymous pipe and the named pipe, both of which can be accessed with the familiar ReadFile and WriteFile functions.

Simple anonymous pipes 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 commonly done between UNIX programs 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 commonly done between UNIX programs

Named pipes Named pipes are much more powerful than anonymous pipes. They are full- duplex and message-oriented, and they allow networked communication. Furthermore, there can be multiple open handles on the same pipe. Named pipes are much more powerful than anonymous pipes. They are full- duplex and message-oriented, and they allow networked communication. Furthermore, there can be multiple open handles on the same pipe.

Named pipes These capabilities, coupled with convenient transaction-oriented named pipe functions, make named pipes appropriate for creating client/server systems. These capabilities, coupled with convenient transaction-oriented named pipe functions, make named pipes appropriate for creating client/server systems.

Anonymous pipes The Windows anonymous pipes allow one-way (half-duplex), character- based IPC. Each pipe has two handles: a read handle and a write handle. The CreatePipe function is as follows. The Windows anonymous pipes allow one-way (half-duplex), character- based IPC. Each pipe has two handles: a read handle and a write handle. The CreatePipe function is as follows.

CreatePipe BOOL CreatePipe ( PHANDLE phRead, PHANDLE phWrite, LPSECURITY_ATTRIBUTES lpsa, DWORD cbPipe) BOOL CreatePipe ( PHANDLE phRead, PHANDLE phWrite, LPSECURITY_ATTRIBUTES lpsa, DWORD cbPipe)

Named pipes Named pipes have several features that make them an appropriate general-purpose mechanism for implementing IPC-based applications, including networked file access and client/server systems, although anonymous pipes remain a good choice for simple byte-stream IPC Named pipes have several features that make them an appropriate general-purpose mechanism for implementing IPC-based applications, including networked file access and client/server systems, although anonymous pipes remain a good choice for simple byte-stream IPC

Named pipes Named pipes are message-oriented, so the reading process can read varying-length messages precisely as sent by the writing process. Named pipes are message-oriented, so the reading process can read varying-length messages precisely as sent by the writing process. Named pipes are bidirectional, so two processes can exchange messages over the same pipe. 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 system using pipes with the same name. Each client can have its own named pipe instance, and the server can respond to a client using the same instance. There can be multiple, independent instances of pipes with the same name. For example, several clients can communicate concurrently with a single server system using pipes with the same name. Each client can have its own named pipe instance, and the server can respond to a client using the same instance.

Named pipe The pipe name can be accessed by systems on a network. Named pipe communication is the same whether the two processes are on the same machine or on different machines. The pipe name can be accessed by systems on a network. 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. Several convenience and connection functions simplify named pipe request/response interaction and client/server connection.

Named pipes CreateNamedPipe creates the first instance of a named pipe and returns a handle. The function also specifies the maximum number of pipe instances and, hence, the number of clients that can be supported simultaneously. CreateNamedPipe creates the first instance of a named pipe and returns a handle. The function also specifies the maximum number of pipe instances and, hence, the number of clients that can be supported simultaneously.

Named pipes HANDLE CreateNamedPipe ( LPCTSTR lpName, DWORD dwOpenMode, DWORD dwPipeMode, DWORD nMaxInstances, DWORD nOutBufferSize, DWORD nInBufferSize, DWORD nDefaultTimeOut, LPSECURITY_ATTRIBUTES lpSecurityAttributes) HANDLE CreateNamedPipe ( LPCTSTR lpName, DWORD dwOpenMode, DWORD dwPipeMode, DWORD nMaxInstances, DWORD nOutBufferSize, DWORD nInBufferSize, DWORD nDefaultTimeOut, LPSECURITY_ATTRIBUTES lpSecurityAttributes)

Named Pipe Connection Functions The server, after creating a named pipe instance, can wait for a client connection using ConnectNamedPipe, which is a server function for NT only. The server, after creating a named pipe instance, can wait for a client connection using ConnectNamedPipe, which is a server function for NT only.

Connect and disconnect named pipe BOOL ConnectNamedPipe ( HANDLE hNamedPipe, LPOVERLAPPED lpOverlapped) BOOL ConnectNamedPipe ( HANDLE hNamedPipe, LPOVERLAPPED lpOverlapped) Finally, the server should call DisconnectNamedPipe to free the handle (pipe instance) for connection with another client. Finally, the server should call DisconnectNamedPipe to free the handle (pipe instance) for connection with another client.

Client and Server Named Pipe Connection The proper connection sequences for the client and server are as follows. First is the server sequence, in which the server makes a client connection, communicates with the client until the client disconnects (causing ReadFile to return FALSE), disconnects the server- side connection, and then connects to another client. The proper connection sequences for the client and server are as follows. First is the server sequence, in which the server makes a client connection, communicates with the client until the client disconnects (causing ReadFile to return FALSE), disconnects the server- side connection, and then connects to another client.

Client and Server Named Pipe Connection hNp = CreateNamedPipe ("\\\\.\\pipe\\my_pipe",...); while (/*server life cycle*/) { ConnectNamedPipe (hNp, NULL); while (ReadFile (hNp, Request,...) {... WriteFile (hNp, Response,...); } DisconnectNamedPipe (hNp); } CloseHandle (hNp);

Client and Server Named Pipe Connection The client connection sequence is as follows, where the client terminates after it finishes, allowing another client to connect on the same named pipe instance. As shown, the client can connect to a networked server if it knows the server name. The client connection sequence is as follows, where the client terminates after it finishes, allowing another client to connect on the same named pipe instance. As shown, the client can connect to a networked server if it knows the server name.

Client and Server Named Pipe Connection WaitNamedPipe ("\\\\ServerName\\pipe\\my_pipe", NMPWAIT_WAIT_FOREVER); hNp = CreateFile ("\\\\ServerName\\pipe\\my_pipe",...); while ( /* Run while no more requests. */ { WriteFile (hNp, Request,...); ReadFile (hNp, Response); } ReadFile (hNp, Response); } CloseHandle (hNp); /* Disconnect */

Named Pipe Transaction Functions

Image shows a typical client configuration in which the client does the following: Image shows a typical client configuration in which the client does the following: Opens an instance of the pipe, creating a long-lived connection to the server and consuming a pipe instance Opens an instance of the pipe, creating a long-lived connection to the server and consuming a pipe instance Repetitively sends requests and waits for responses Repetitively sends requests and waits for responses Closes the connection Closes the connection

Named Pipe Transaction Functions The common WriteFile, ReadFile sequence could be regarded as a single client transaction, and Windows provides such a function for message pipes. The common WriteFile, ReadFile sequence could be regarded as a single client transaction, and Windows provides such a function for message pipes. BOOL TransactNamedPipe ( HANDLE hNamedPipe, LPVOID lpWriteBuf, DWORD cbWriteBuf, LPVOID lpReadBuf, DWORD cbReadBuf, LPDWORD lpcbRead, LPOVERLAPPED lpOverlapped) BOOL TransactNamedPipe ( HANDLE hNamedPipe, LPVOID lpWriteBuf, DWORD cbWriteBuf, LPVOID lpReadBuf, DWORD cbReadBuf, LPDWORD lpcbRead, LPOVERLAPPED lpOverlapped)

Named Pipe Transaction Functions CallNamedPipe is the second client convenience function: CallNamedPipe is the second client convenience function: BOOL CallNamedPipe ( LPCTSTR lpPipeName, LPVOID lpWriteBuf, DWORD cbWriteBuf, LPVOID lpReadBuf, DWORD cbReadBuf, LPDWORD lpcbRead, DWORD dwTimeOut) BOOL CallNamedPipe ( LPCTSTR lpPipeName, LPVOID lpWriteBuf, DWORD cbWriteBuf, LPVOID lpReadBuf, DWORD cbReadBuf, LPDWORD lpcbRead, DWORD dwTimeOut)

Named Pipe Transaction Functions CallNamedPipe does not require a permanent connection; instead it makes a temporary connection by combining the following complete sequence: CallNamedPipe does not require a permanent connection; instead it makes a temporary connection by combining the following complete sequence: CreateFile CreateFile WriteFile WriteFile ReadFile ReadFile CloseHandle CloseHandle into a single function

Peeking at Named Pipe Messages In addition to reading a named pipe using ReadFile, you can also determine whether there is actually a message to read using PeekNamedPipe. In addition to reading a named pipe using ReadFile, you can also determine whether there is actually a message to read using PeekNamedPipe.

Peeking at Named Pipe Messages BOOL PeekNamedPipe ( HANDLE hPipe, LPVOID lpBuffer, DWORD cbBuffer, LPDWORD lpcbRead, LPDWORD lpcbAvail, LPDWORD lpcbMessage)

Mailslots A Windows mailslot, like a named pipe, has a name that unrelated processes can use for communication. A Windows mailslot, like a named pipe, has a name that unrelated processes can use for communication.

Mailslots Here are the significant characteristics of mailslots. Here are the significant characteristics of mailslots. A mailslot is one-directional. 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 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. 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. Mailslots can be located over a network domain. Message lengths are limited. Message lengths are limited.

Mailslots Using a mailslot requires the following operations. Using a mailslot requires the following operations. Each server creates a mailslot handle with Creat slot. Each server creates a mailslot handle with Creat slot. The server then waits to receive a mailslot message with a ReadFile call. The server then waits to receive a mailslot message with a ReadFile call. A write-only client should open the mailslot with CreateFile and write messages with WriteFile. The open will fail (name not found) if there are no waiting readers. A write-only client should open the mailslot with CreateFile and write messages with WriteFile. The open will fail (name not found) if there are no waiting readers. A client's message can be read by all servers; all of them receive the same message. A client's message can be read by all servers; all of them receive the same message.

Using Mailslots

Creating and Opening a Mailslot The mailslot servers (readers) use Creat slot to create a mailslot and to get a handle for use with ReadFile. There can be only one mailslot of a given name on a specific machine, but several systems in a network can use the same name to take advantage of mailslots in a multireader situation. The mailslot servers (readers) use Creat slot to create a mailslot and to get a handle for use with ReadFile. There can be only one mailslot of a given name on a specific machine, but several systems in a network can use the same name to take advantage of mailslots in a multireader situation.

Creating and Opening a Mailslot HANDLE Creat slot (LPCTSTR lpName, DWORD cbMaxMsg, DWORD dwReadTimeout, LPSECURITY_ATTRIBUTES lpsa) HANDLE Creat slot (LPCTSTR lpName, DWORD cbMaxMsg, DWORD dwReadTimeout, LPSECURITY_ATTRIBUTES lpsa)

Parameters lpName points to a mailslot name of this form: lpName points to a mailslot name of this form: \\.\mailslot\[path]name The name must be unique. The period (.) indicates that the mailslot is created on the current machine. \\.\mailslot\[path]name The name must be unique. The period (.) indicates that the mailslot is created on the current machine. cbMaxMsg is the maximum size (in bytes) for messages that a client can write. A value of 0 means no limit. cbMaxMsg is the maximum size (in bytes) for messages that a client can write. A value of 0 means no limit. dwReadTimeout is the number of milliseconds that a read operation will wait. A value of 0 causes an immediate return, and MAILSLOT_WAIT_FOREVER is an infinite wait (no time-out). dwReadTimeout is the number of milliseconds that a read operation will wait. A value of 0 causes an immediate return, and MAILSLOT_WAIT_FOREVER is an infinite wait (no time-out).