Introduction
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.
Background
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:
- Thread.Abort
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++ :(.
Overlapped IO
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 ReadFile, WriteFile functions.
System.IO.FileStream
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 PipeListenner and PipeClient after the TCPListener and TCPClient classes, so their use is pretty straightforward:
PipeListenner
Dim WithEvents Listenner As New _
NamedPipes.PipeListener("myPipe")
Listenner.StartListenning
Private Sub Listenner_ClientConnected(ByVal sender As Object, _
ByVal e As NamedPipes.ClientConnectedEventArgs) _
Handles P.ClientConnected
e.ClientStream.Read
e.CleintStream.Write
...
End Sub
PipeClient
Dim Client As New NamedPipes.PipeClient("\\.\pipe\myPipe")
Client.Connect
Client.ClientStream.Read
Client.ClientStream.Write
...
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!
