WCF Named Pipe Streaming

Question

I have implemented a server/client test rig that uses streamed transfer mode with a net.pipe binding. This is all kind of working however I am hitting an issue when the actual server's stream implementation blocks on an empty buffer. Even if i remove all synchronization, set the concurrency mode to multiple I am having an issue where my client application is blocking on stream.Read.

So my client initiates a connection to the server with a "GetStream" call (on a non-UI thread), the actual stream implementation that's returned by the server is a blocking stream (say NetStream for example) so it will block when there are no bytes available to read. This is causing a complete lockup of the service host so now the client cannot make any further calls until the stream.read operation unblocks.

Can someone shed some light on this behavior?

Answer 1

I have solved a working code for anonymous pipes, named pipes asynchronous and synchronous. From my experience I can tell that, you just cannot have shared memory buffer "empty". Even in Asynchronous, I believe, background threads are created to read and write synchronously.

So at the moment just consider this for a fact that,

the server must first send write to buffer => the client should read it => Client must write back to that buffer => Server must read it.

That cycle has to repeat forever for applications to not freeze. I am beginning to think this is what makes shared memory communication different via server/client socket. In shared memory approach you might not have to worry about synchronization also it dedicates client to a server such that client cannot exist with a server.

Answer 2

You should look at using the older 'async' style Begin/End Read/Write methods to allow asynchronously communication. Unfortunately there is no async/await support for named pipes in .net - however, you can wrap them using the TaskFactory.FromAsync methods.