My expectation is that is this the case, that after creating a NamedPipeServerStream with PipeOptions.Asynchronous (and the client side as well), that one can still perform synchronous Read/Write operations on the pipe.
However, I have found that when the server synchronously writes bytes which exceed the size of the out buffer, the client end blocks on the read, never to return, even though the server has written the appropriate amount of data to satisfy that read.
Update: I have not yet been able to make a simple repro case, but I have isolated what I think to be suspicious results from the PipeStream class. I have the following code:
byte[] buffer = new byte[ 66754 ];
int n1 = pipeStream.Read( buffer, 0, 66754 ); // Read returns 65536
int n2 = pipeStream.Read( buffer, buffer.Length - 1218, 1218 ); // Read blocks
This code is executed under the circumstances where the other side of the pipe has written 66754 bytes of data and the read side has not yet read this data (note, that the in and out max buffersize of the pipe at both ends is 65536 and that 65536 + 1218 == 66754).
When this code executes, the first read returns with n1 == 65536, indicating that not all the data I expected was read, so I execute another read, asking for the remaining data. This read blocks indefinitely, never to return.
However, before the second read, when I inspect the buffer, I see the expected data that was written, even after the 65535 position!
It seems like the first Read read all the data, but only returned the max buffer size, so the second read hangs because there is no more data to be read. But, I do not know that because I was told, incorrectly, the amount of data read on the first Read.
Now, a slight modification to this code. This new code runs in exactly the same conditions as the previous.
byte[] buffer = new byte[ 66754 ];
int n1 = pipeStream.Read( buffer, 0, 65536); // Read returns 65536
int n2 = pipeStream.Read( buffer, buffer.Length - 1218, 1218 ); // Read blocks
Note that now the first Read has asked to read only the max buffer size of 65536. In this case, n1 == 65536, and when the second read takes place, it returns successfully with n2 == 1218.
Here, instead of the first read asking for all the data, it asks for the max buffersize. These are expected correct results of the Reads.
This suggests that there is a bug in the PipeStream code, where it returns the incorrect value from Read.
I will continue to try to make a simple repro case for this.
Another Update: Found this: NamedPipe's ReadByte hangs Seems relevant to my issues.