This article shows the fine points of taking advantage of the Windows Overlapped API for asynchronous communication through named pipes. The greatest achievement of this code compared to other similar ones is that the server and client actually stop when you tell them to.
While I was trying to set up some means of inter-process communication between a Windows service and multiple instances of an application (one for each user), I stumbled upon various articles describing how to achieve this with named pipes. The idea seemed promising, but all the sample code I downloaded and tried out had the same weak point: the server loop (running on a different thread) locked while waiting for a client to connect. The only ways that one could use to make the server stop where:
I find this to be a very ugly solution since you can't really clean-up after the thread this way.
- Have a client connect to the server
The service can connect to itself (!) in order for the server thread to unlock. This method is not very accurate, and shouts "workaround"! One of the articles I read seems to have the correct angle to solve the problem and is right here in the CodeProject, but.... oops! its in C++
All you have to do to use overlapped IO is to specify the
FILE_FLAG_OVERLAPPED flag in the
CreateNamedPipe (server side) and
CreateFile (client side) APIs. From then on, everything is pretty easy since you can pass a handle to a
ManualResetEvent to the OS (inside the
NativeOverlapped structure) and it will signal you when your async operation is complete. This applies to all IO functions with an
lpOverlapped parameter in their signature. Thus,
ConnectNamedPipe (server side) becomes truly asynchronous, but also the
It seems strange that this class should be mentioned here, but if one the examined sample code on the named pipes, he would see that they are different from regular files only in how they are created (on the server side), while the handle that you obtain is in essence a file handle! So why not use the already existing
FileStream class for IO operations? The constructor that receives a file handle came extremely handy here!
Using the code
I modeled (or at least tried to) the
PipeClient after the
TCPClient classes, so their use is pretty straightforward:
Dim WithEvents Listenner As New _
Private Sub Listenner_ClientConnected(ByVal sender As Object, _
ByVal e As NamedPipes.ClientConnectedEventArgs) _
Dim Client As New NamedPipes.PipeClient("\\.\pipe\myPipe")
The preceding "code" demonstrates very simply how these classes are to be used. For a more advanced implementation (including multithreaded operation), download the demo application source code and take a look inside.
Points of interest
As explained by the before mentioned article by Rob Manders, all the "magic" is in this line of code:
Select Case Threading.WaitHandle.WaitAny(mSyncEvents, -1, False)
What is peculiar about this piece of code is that it doesn't work... at least, not always! It seems to be working 99% while the application is executing under the "umbrella" of Visual Studio, but if you run the executable directly, it will crash miserably as soon as a client connects.
The alternative is:
Select Case NativeMethods.WaitForMultipleObjects(mSyncEvents.Length, _
mSyncEvents, False, UInteger.MaxValue)
but it will always fail if running under Visual Studio, but will work after many builds when running the release executable. I am really hoping that this is just caused by the fact that my box isn't at its best these days, because I can't really find an explanation for it! Maybe some of the people who will read this article may be able to offer some clue as to what might be going on here!