Windows named pipes in practice
With Windows named pipes, what is the proper way to use the CreateNamedPipe , ConnectNamedPipe , DisconnectNamedPipe , and CloseHandle calls?
I am making a server app which is connecting to a client app which connects and disconnects to the pipe multiple times across a session.
When my writes fail because the client disconnected, should I call DisconnectNamedPipe , CloseHandle , or nothing on my handle.
Then, to accept a new connection, should I call CreateNamedPipe and then ConnectNamedPipe , or just ConnectNamedPipe ?
I would very much like an explanation of the different states my pipe can be in as a result of these calls, because I have not found this elsewhere.
Language: Python using the win32pipe , win32file and win32api libraries.
Pipe settings: WAIT, no overlap, bytestream.
2 Answers 2
It is good practice to call DisconnectNamedPipe then CloseHandle , although CloseHandle should clean everything up.
The MSDN documentation is a little vague and their server example is pretty basic. As to whether you reuse pipe handles, it seems that it is your own choice. Documentation for DisconnectNamedPipe seems to indicate that you can re-use a pipe handle for a new client by calling ConnectNamedPipe again on that handle after disconnecting. The role of ConnectNamedPipe seems to be to assign a connecting client to a handle.
Make sure you are cleaning up pipes though as MSDN states the following
Every time a named pipe is created, the system creates the inbound and/or outbound buffers using nonpaged pool, which is the physical memory used by the kernel. The number of pipe instances (as well as objects such as threads and processes) that you can create is limited by the available nonpaged pool. Each read or write request requires space in the buffer for the read or write data, plus additional space for the internal data structures.
I’d also bare the above in mind if you are creating/destroying a lot of pipes. My guess that it would be better to operate a pool of pipe handles if there are many clients and have some grow/shrink mechanism to the pool.
Named Pipe Server Using Overlapped I/O
The following is an example of a single-threaded pipe server that uses overlapped operations to service simultaneous connections to multiple pipe clients. The pipe server creates a fixed number of pipe instances. Each pipe instance can be connected to a separate pipe client. When a pipe client has finished using its pipe instance, the server disconnects from the client and reuses the pipe instance to connect to a new client. This pipe server can be used with the pipe client described in Named Pipe Client.
The OVERLAPPED structure is specified as a parameter in each ReadFile, WriteFile, and ConnectNamedPipe operation on the pipe instance. Although the example shows simultaneous operations on different pipe instances, it avoids simultaneous operations on a single pipe instance by using the event object in the OVERLAPPED structure. Because the same event object is used for read, write, and connect operations for each instance, there is no way to know which operation’s completion caused the event to be set to the signaled state for simultaneous operations using the same pipe instance.
The event handles for each pipe instance are stored in an array that is passed to the WaitForMultipleObjects function. This function waits for one of the events to be signaled, and returns the array index of the event that caused the wait operation to complete. The example in this topic uses this array index to retrieve a structure containing information for the pipe instance. The server uses the fPendingIO member of the structure to keep track of whether the most recent I/O operation on the instance was pending, which requires a call to the GetOverlappedResult function. The server uses the dwState member of the structure to determine the next operation that must be performed for the pipe instance.
Overlapped ReadFile, WriteFile, and ConnectNamedPipe operations can finish by the time the function returns. Otherwise, if the operation is pending, the event object in the specified OVERLAPPED structure is set to the nonsignaled state before the function returns. When the pending operation finishes, the system sets the state of the event object to signaled. The state of the event object is not changed if the operation finishes before the function returns.
Because the example uses manual-reset event objects, the state of an event object is not changed to nonsignaled by the WaitForMultipleObjects function. This is important, because the example relies on the event objects remaining in the signaled state, except when there is a pending operation.
If the operation has already finished when ReadFile, WriteFile, or ConnectNamedPipe returns, the function’s return value indicates the result. For read and write operations, the number of bytes transferred is also returned. If the operation is still pending, the ReadFile, WriteFile, or ConnectNamedPipe function returns zero and the GetLastError function returns ERROR_IO_PENDING. In this case, use the GetOverlappedResult function to retrieve the results after the operation has finished. GetOverlappedResult returns only the results of pending operations. It does not report the results of operations that were completed before the overlapped ReadFile, WriteFile, or ConnectNamedPipe function returned.
Before disconnecting from a client, you must wait for a signal indicating the client has finished. (Flushing the file buffers would defeat the purpose of overlapped I/O, because the flush operation would block the execution of the server thread while it waits for the client to empty the pipe.) In this example, the signal is the error generated by trying to read from the pipe after the pipe client closes its handle.
komuw / python_named_pipe.py
| import os |
| import errno |
| import time |
| «»» |
| The linux pipe buffers are implemnted as circular buffers[1]. |
| A consequence of the circular buffer is that when it is full and a subsequent write is performed: |
| (a) then it starts overwriting the oldest data[2]. |
| (b) Alternatively, the routines that manage the buffer could prevent overwriting the data and return an error or raise an exception. |
| Whether or not data is overwritten is up to the semantics of the buffer routines or the application using the circular buffer[2]. |
| TODO: investigate whether namedPipes in Linux overwrite data [as in (a) above or raise error as in (b)] |
| TODO: use async operations; eg reading the pipe, writing to pipe etc |
| 1. http://www.pixelbeat.org/programming/stdio_buffering/ |
| 2. https://en.wikipedia.org/wiki/Circular_buffer |
| «»» |
| FIFO = ‘komusNamedPipe’ |
| try : |
| os . mkfifo ( FIFO ) |
| except OSError as e : |
| if e . errno != errno . EEXIST : |
| raise e |
| print ( «Opening FIFO. » ) |
| with open ( FIFO ) as fifo : |
| print ( «FIFO opened» ) |
| while True : |
| data = fifo . read () |
| if len ( data ) == 0 : |
| print ( «Writer closed» ) |
| time . sleep ( 3 ) |
| print ( «slept for 3 seconds» ) |
| print () |
| print ( ‘Read: «<0>«‘ . format ( data )) |
| print () |
| print ( «end of read program» ) |
| # in terminal 1: |
| # > python read_named_pipe.py |
| # in terminal 2: |
| # > echo «sina tabu» > komusNamedPipe |
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.