Charteris Community Server

Welcome to the Charteris plc Community
Welcome to Charteris Community Server Sign in | Join | Help
in Search

Chris Dickson's Blog

Exploring the WCF Named Pipe Binding - Part 1

This is the first in a series of posts in which I will aim to explain some details of the named pipe binding provided by Windows Communication Foundation (WCF), discovered during the course of some exploring I have been doing. My motivations for looking into this were:

  1. The standard binding (NetNamedPipeBinding) exposes very few properties relating to configuration of the underlying transport mechanism. Having some awareness of the Windows named pipe APIs from previous work, I was interested to understand how the WCF binding mapped to the underlying transport protocol; which named pipe configuration options were "baked into" the WCF implementation and which might be controlled/tweaked with a bit of work in the channel stack.
  2. I wanted to understand in more detail the security characteristics of the binding.
  3. I was just nosey :-) 

In this post I will start by looking at the how the named pipe used by a service endpoint with the NetNamedPipe binding is created, and how clients locate it in order to connect.

I had expected that if I looked into the service process using a tool like Process Explorer, I would see it holding a handle to a named pipe with a name closely related to the URI of the endpoint. What I see instead is a handle to a pipe named something like...


... clearly the pipe name has been created using a GUID. I also note that the name of the pipe changes each time I stop and restart my service host, so the GUID is being regenerated each time the endpoint runtime is built by WCF.

How then does a client of the service know how to communicate with the endpoint? Somehow it must be able to resolve the well-known URI for the endpoint into whatever is the current name of the pipe it must use to send messages to the service. It turns out that this is accomplished using what amounts to a mini metadata publishing mechanism which is exclusive to the NetNamedPipe binding. This mechanism is based on a named Windows file mapping object backed by the system paging file. It is the name of this object which is invariant, and directly derived from the endpoint URI... though in a far from obvious way.

So in order to locate the correct pipe, a client of a WCF NetNamedPipe service endpoint has to:

  • know that the special metadata mechanism exists
  • know how to derive from the endpoint URI the name of the file mapping object through which the metadata is published
  • located the file mapping object and use it to open a view on the shared memory
  • know how to interpret the metadata stored in the shared memory, and translate it into the name of the pipe currently being used by the endpoint

Some more details for those who are interested:

Deriving the file mapping object name from the URI

The shared memory file mapping object created by the service endpoint listener (System.ServiceModel.Channels.PipeConnectionListener) has a name which looks something like this:


This is derived from the following components:

["net.pipe"] [:E|:H] [base-64 encoded byte[] X]

Where the X is constructed as:

    - when the second component is :E   :    UTF8 encoding of ["net.pipe://"] [URI hostname-or-wildcard*] [URI path or parent path]

    - when the second component is :H   :    the SHA-1 hash of the above (used when the UTF8 encoding of the above exceeds 127 bytes)

*The URI hostname-or-wildcard depends on the HostNameComparisonMode setting for the endpoint's transport binding - this property is set to HostNameComparisonMode.StrongWildcard in the standard NetNamedPipeBinding, and is not exposed as a property of the binding itself. This means that this component of the name will be "+" (the strong wildcard symbol) unless a custom binding has been used to tweak the HostNameComparisonMode property of the transport binding element.

Data stored by the service in the shared memory object

The service stores 20 bytes of data in the shared memory, representing an instance of the structure System.ServiceModel.Channels.PipeSharedMemory+SharedMemoryContents, which looks like this...

struct SharedMemoryContents
    public bool isInitialized;
    public Guid pipeGuid;
The client uses the GUID stored in this object to construct the pipe name through which to connect to the service endpoint.

Of course, the WCF client stack knows how to jump through these hoops, as it uses the same set of System.ServiceModel types as the service used to set up the mechanism. So you don't really need to know anything about all this if your service client is also a WCF application using the standard binding... which it will be if you are doing things as the WCF designers intended: the named pipe binding was designed solely for WCF-to-WCF scenarios. 

That's not to say that, in principle, there is any fundamental reason why a named pipe binding to a WCF service should not be able to support any arbitrary client implementation which knows how to write messages to and read messages from a named pipe. Perhaps there are integration scenarios involving legacy unmanaged code or mixed technologies on a single box, where a more open named pipe binding might be useful, not least because the underlying transport mechanism is very fast. But the standard NetNamedPipe binding won't help with this. In practice, it is going to be much easier to use one of the bindings based on standard interoperable protocols, or by providing a COM wrapper around a WCF client implementation.

Published May 19 2008, 03:18 PM by chrisdi
Filed under: ,



Soma Natarajan said:

Thanks for the article. It provides insight about named pipe binding.

June 10, 2008 8:12 PM

Jeldrik said:

Great article. I was wondering why I can't open the pipe with "CreateFile" from C++, now I know the answer. Even though I would like to have used WCF even in this scenario :-( .

July 3, 2008 1:39 PM


(1)Chris wrote excellent blog about Named pipe Binding

July 11, 2008 9:42 PM

Greg said:

Yes, this is quite frustrating... I was planning to create a very simple unmanaged named-pipe based server to be consumed by a WCF client.   I wonder why they jumped through these hoops rather than just deriving the name of the pipe from the endpoint uri?

September 12, 2008 7:07 PM

shazia said:

The article is lovely.  Information of this article is very useful and important.

December 17, 2008 10:59 AM said:

I am very glad to see these lovely information.

May 9, 2009 12:32 PM

Dan said:

This article is very helpful.  It does raise the question why Microsoft would intentionally impede the use of named pipes between WCF and non-WCF clients.  That said, does anyone have any sample code that reads from the metadata mechanism to obtain the name of the named pipe for a non-WCF application?

July 15, 2009 6:05 PM

Jaspreet said:

Does this means that the >net Application that uses WCF NamedPipes can't communicate with Non-WCF (Legacy application) ?

I have an application thats written in Dos almost 15 years back and i need to communicate with that over Named-Pipes. What i am undetstanding from this article is that i can;t use WCF to do that, Is it correct?

November 12, 2009 6:47 PM

chrisdi said:


You cannot use the standard WCF netNamedPipes binding to communicate with your legacy application, for the reasons explained in my post.

You could use WCF to communicate with it, but you would need to write a custom binding including a custom transport binding element - and WCF provides nothing out of the box to help you with this.

November 16, 2009 10:08 AM

Anu said:

Nice post. I was able to decipher the named pipe from what Process Explorer showed me as \BaseNamedObjects\net.pipe:EbmV0LnBpcGU6Ly8rLw==

Turns out that this is net.pipe://+/.

That means this was intercepting all my WCF named pipe client communication. This happened as soon as i ran it as admin.The bug was i had the named pipe as net:pipe://mynamedpipe which means with the default hostnamecomparison mode, it effectively all netNamedPipe communication on the box.

Here is the powershell script i used to decipher

$e = 'bmV0LnBpcGU6Ly8rLw=='

$b = [System.Convert]::FromBase64String($e)


May 18, 2010 12:30 AM

Chris Dickson's Blog said:

As those who have read my earlier post will be aware, when a WCF client wishes to establish communication

October 20, 2010 6:26 PM

What is the best choice for .net inter-process communication? - Programmers Goodies said:

Pingback from  What is the best choice for .net inter-process communication? - Programmers Goodies

July 6, 2011 5:47 AM

Training : Windows Communication Foundation | Stephen Haunts { Coding in the Trenches } said:

Pingback from  Training : Windows Communication Foundation | Stephen Haunts { Coding in the Trenches }

July 24, 2013 10:09 PM

Windows named pipe used in service not working | Q Sites said:

Pingback from  Windows named pipe used in service not working | Q Sites

August 3, 2013 1:19 PM

Leave a Comment

Powered by Community Server (Commercial Edition), by Telligent Systems