C ++ and C # processes communicate through named Pipelines

Named Pipe is a simple mechanism for inter-process communication (IPC. A named pipe supports reliable, one-way, or two-way data communication between different processes on the same computer or across different computers on a network. Designing an application with a named pipeline is actually very simple, and you do not need to have a thorough understanding of the basic network transfer protocol (such as TCP/IP or IPX) in advance. This is because the named pipe uses the Microsoft network provider (msnp) redirection to establish communication between processes through a network. In this way, applications do not have to worry about the details of network protocols.

Command pipeline is a mechanism designed around the Windows file system, using the "namedpipefilesystem, npfs) interface. Therefore, client and server applications can use standard Win32 file system API functions (such as readfile and writefile) to send and receive data. Through these API functions, applications can directly use the Win32 File System naming rules and the security mechanism of WindowsNT/Windows2000 file systems. Npfs relies on the msnp reconfigurator to send and receive Named Pipe data online. In this way, you can implement the "protocol-independent" feature of the interface: if you use a named pipe in your own applications to establish communications between different processes on the internet, programmers do not have to worry about the details of basic network transmission protocols (such as TCP and IPX.

Clients and servers

The biggest feature of the named pipeline is the establishment of a simple client/server program design system. In this architecture, data between the client and the server can be transmitted in one direction or flow in two directions. The difference between the named MPs Queue Server and the client is that the server is the only process that has the permission to create the named MPs queue and can only accept connection requests from the MPs queue client. For a client application, it can only establish connections with a named pipe server. Once a connection is established between a client application and a server application, both processes can read and write data in the pipeline to the standard Win32 function. These functions include readfile and writefile.

Server

To implement a named pipe server, you must develop an application, create one or more "instances" of the named pipe, and then access them by the client. For the server, an MPS queue instance is actually a handle used to receive a connection request from a local or remote client application. Follow these steps to write a basic server application:

1) Use the API function createnamedpipe to create a named pipeline instance handle.

2) use the API function connectnamedpipe to listen to client connection requests on the named pipeline instance.

3) use the API function readfile to receive data from the client. Use the API function writefile to send data to the client.

4) use the API function disconnectnamedpipe to disable the named pipe connection.

5) use the closehandle function to close the handle of the named pipeline instance.

First, our server process needs to call createnamedpipe to create a named pipeline instance.

The following is a prototype of the createnamedpipe () function:

Handle createnamedpipe (

Lptstr lpname, // pointer to the pipe name

DWORD dwopenmode, // pipeline open mode

DWORD dwpipemode, // pipe mode

DWORD nmaxinstances, // maximum number of instances

DWORD noutbuffersize, // output cache size

DWORD ninbuffersize, // enter the cache size

DWORD ndefatimetimeout, // timeout setting

Lpsecurity_attributes lpsecurityattributes // Security Attribute pointer

);

The main parameters are as follows:

Lpname is the name of the MPs queue. The name of the MPs queue is in the following format: \ servername \ PIPE \ pipename. Specifically, the first part \ servername specifies the name of the server. The named pipeline service is created on this server, and it needs to "listen" for incoming connection requests ", the string can be expressed as a decimal point ". "(indicating the local machine), asterisk (current network field), domain name or a real service; the second part \ pipe is an unchangeable hard-coded string, to indicate that the file is from npfs, case-insensitive; the third part \ pipename is the name that the application can uniquely define and identify a named pipe, and can set a multi-level directory.

The dwopenmode parameter indicates the transmission direction, I/O control, and security mode of an MPS queue after it is created. The pipe_access _ flag determines the flow of data between the client and the server in the pipeline. Pipe available
The _ access_duplex flag opens an MTS queue in bidirectional transmission mode. That is to say, data can be transmitted between the client and the server in two directions. In addition, you can use the pipe_access_inbound or pipe_access_outbound flag to open an MTS queue in one-way transmission. That is to say, data can only be transmitted from the client to the server or from the server to the client.

The dwpipemod named pipeline provides two basic communication modes: the byte mode (pipe_type_byte) and the message mode (pipe_type_message ). In the byte mode, information flows between the customer and the server in the form of continuous byte streams, which means that for client and server applications, in any specific period of time, you cannot know exactly how many bytes are read or written from the pipeline. In this communication mode, after one party writes a certain number of bytes to the pipeline, it cannot ensure that the other party can read the same number of bytes. In message mode, the client and server send and receive data through a series of discontinuous data packets. Each message sent from the pipeline must be read as a complete message.

For more information about other functions and their parameters, see msdn.

The server calls this function. If an instance MPs queue can be used before the predefined timeout value is changed to zero, the instance is created successfully and the MPs queue handle is returned to listen for connection requests from the client.

Client

To implement a named pipe client, you must develop an application to establish a connection with a named pipe server. Note that the client cannot create named pipe instances. However, the client can open ready-made instances from the server. The following steps explain how to write a basic client application:

1) Use the API function waitnamedpipe to wait for a named pipeline instance for your use.

2) use the createfile API function to establish a connection with the named pipe.

3) use the API functions writefile and readfile to send data to or receive data from the server.

4) use the closehandle function to close the opened named pipeline session.

Before establishing a connection,The client needs to use the waitnamedpipe function to check whether there is a ready-made named pipeline instance.. After waitnamedpipe is successfully completed, the client needs to use the createfile API function to open a handle pointing to the server named pipeline instance.

Simply put, the server calls createnamedpipe to create an MPS queue. If an instance MPs queue can be used before the predefined timeout value is changed to zero, the MPs queue is created successfully and the MPs queue handle is returned, to listen for connection requests from clients. On the other hand, the client uses the waitnamedpipe () function to wait for the server process to connect to the instance from the customer. If an MTS queue is available for connection before the timeout value is zero, the function returns a successful response and calls the connection to the server by calling createfile () or callnamedpipe. At this time, the server will accept the customer's connection request and establish a connection. The connectnamedpipe () function called by the server waiting for the client to establish a connection will also return a successful result. Then, the two ends of the MPs queue can communicate with each other.

In terms of the call sequence, the client first makes the createfile () of the server successfully created the instance within a limited time period through waitnamedpipe (), and then the two parties connect to the instance through connectnamedpipe () and createfile, after a file handle is returned for communication, the customer and the service provider can communicate with each other.

Bool ret =: waitnamedpipe (fullpipename, 5000 );

If (! RET)

{

// Clientmsg = "the MPs queue is busy or has not been started ...... \ N ";

Return;

}

Handle hpipe =
: Createfile (fullpipename,

Generic_read | generic_write,

File_pai_read | file_pai_write,

Null,

Open_existing,

File_attribute_normal,

Null );

After a connection is established, the client and server can exchange information with each other through readfile () and writefile () and the obtained pipeline handle in the form of file read/write. When the communication between the client and the server ends or the client needs to be disconnected for some reason, the client calls the closefile () function to close the open pipeline handle, and the server then calls the disconnectnamedpipe () function. Of course, the server can also terminate the connection by unilaterally calling disconnectnamedpipe. Call closehandle () after terminating the connection to close the pipeline.