An article on creating a library that takes advantage of the native Win32 overlapped IO for asynchronous named pipe communication.
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.
I find this to be a very ugly solution since you can't really clean-up after the thread this way.
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 ReadFile, WriteFile functions.
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!
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.
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.
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!
I have found this code very simple and very usefull for me, thank you.
can I suggest a to add client to send data to server?
The C# zip you mentioned creating would be a great edit to this article (or for a new one adapted and put in the C# section). The link you mentioned below is broken. Could you post it again? There are still many of us out there looking for a solution like this because some companies are not allowing us to take advantage of the new .Net 3.x features.
Thanks for a great article and for any info!
Does it work under a Windows service ?
I live in France, so excuse me for my bad English !
I'm trying to create a NamedPipe Listener under a Windows Service, but I can't connect a client from a classic Windows form-based application.
If I move the same code onto another classic Windows form, it works.
My service is running as "LocalSystem".
Does anybody succeeded to make this NamedPipe reference with a Windows service ?
Can you post the same implementation using System.IO.Pipes classes.
It means "tried to read from or write into protected memory"
Are you using the C# or VB.Net version?
Just read the posts above and you will find out that I abandoned the vb.net version and have provided a C# version that works.
After some research I have discovered why the Threading.WaitHandle.WaitAny crashes outside of the debugger. The overlapped structure must be marshalled to unmanaged memory before calling ConnectNamedPipe. After I made the necessary changes, I can now use the managed WaitAny in the debugger and standalone.
Danny, could I ask a big favour of you and get a bit more detail on the changes you made to get this working? It would really get me out of a hole . Thanks in anticipation.
I'm using VB.NET 2005 in VS 2005 Prof. and try to get this example to run outside VS. If I uncomment the 3 lines in Sub OnServiceRequest (PipeListenner.vb) I get an OutOfDate-Warning for the Handle-Property, saying I'd use SafeWaitHandle instead (which results in big syntax issues, if changed).
If I leave the lines as they are and rebuild the entire project, the executable from TestNamedPipes/bin/Release still crashes.
Would anyone know where and how in this code I can set security so that the pipe accepts connections from anyone?
I have a service running as local system, and a GUI in the user account. I'm getting a pipe could not be opened error. I know I need to set the security, but am not familiar enough to figure out what to do and where to put it. Any help would be appreciated.
Re: Would anyone know where and how in this code I can set security so that the pipe accepts connections from anyone?
Can you be a little more specific? Under what account is the service running?
I downloaded your demo source code, ran it, and it worked great. I have need to attached to a streaming xml pipe for an application. So in borrowing your named pipe library and and putting in my app I get a CreateFile error -- whereas the inner message is access denied. Any help would be appreciated.
Crach On "Start Without Debugging".
Thanks For your code. I just need it.
Any Idea how to solve the problem ?
Re: Crach On "Start Without Debugging".
I got this thing fixed, I just didnt have enough time to post an article about it. What I did is I rewrote the whole thing with C#. The main difference between VB and C# (I was unaware it even existed before this) is the Unsafe blocks in which you can actually use C style pointers (not IntPtr but *SomeStructure). This comes very handy when dealing with calls to unmanaged code and in our case it fixed the problem. I will try and post a link to download the thing (source code and everything) when I get home.
You can download the C# project zip here. The new project seems to be working well and it hasnt crashed even once.
Great. Thanks a lot !
The link seems to be broken - could you upload the file again?
Thank you very much for this sample.
Thanks for the contribution. Couple quick questions. I'm currently developing a scaled down version of NLog. I'm have'n a very difficult time with UDP. Just can't handle the constant blast of debug lines.
I will test this myself, but was curious what your experience, if any, with your solution and "high volumes" of traffic?