Add Kestrel named pipes transport

[JamesNK]

Addresses #14207

[davidfowl]

I do wonder if it makes sense to also build a Stream based transport mechanism that does all of this boilerplate that would then support any sort of duplex stream implementation.

[JamesNK]

I think there are always going to be small differences in each implementation. For example, QuicStream is a Stream, but we need to use WriteAsync(Memory<byte> buffer, bool complete) and QuicStream.ReadsComplete in the inner loops. And we need to react differently depending upon QUIC exceptions.

But in saying that, named pipe streams are pretty vanilla usages of Stream. A little too vanilla actually. I'm not sure if it is hidden by the named pipe stream abstraction or not, but there doesn't appear to be any way to indicate whether a named pipe ended gracefully or was aborted/connection lost. The only way to end a named pipe stream from the server is calling Disconnect (or dispose), and ReadAsync just returns 0 when the other side of the pipe disconnects.

[JamesNK]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[davidfowl]

I think there are always going to be small differences in each implementation. For example, QuicStream is a Stream, but we need to use WriteAsync(Memory buffer, bool complete) and QuicStream.ReadsComplete in the inner loops. And we need to react differently depending upon QUIC exceptions.

But in saying that, named pipe streams are pretty vanilla usages of Stream. A little too vanilla actually. I'm not sure if it is hidden by the named pipe stream abstraction or not, but there doesn't appear to be any way to indicate whether a named pipe ended gracefully or was aborted/connection lost. The only way to end a named pipe stream from the server is calling Disconnect (or dispose), and ReadAsync just returns 0 when the other side of the pipe disconnects.

Maybe? But we should have it as an option. The HttpClient support is similar, and you need to implement a wrapper stream to change that behavior.

[mconnew]

With regards detecting a named pipe closing, it's probably even more complicated than you think. Although I haven't got to running the code yet (battling with project issues), you can see my attempt to duplicate the native P/Invoke based logic from .NET Framework using PipeStream on the close path here. You can see that we explicitly send a 0 byte write on the connection. I just checked the implementation of PipeStream.WriteAsync and it looks like we might have a problem here as it converts a zero byte write into a no-op and doesn't do anything. Based on the .NET Framework WCF named pipes implementation, a zero byte write should be actually sent to the underlying OS which pops out as a zero byte read on the receiving end signaling shutting down of the connection. I can probably fix this by getting the native handle and doing a P/Invoke to send a 0 byte write if needed. But I suspect there's a behavior change needed in PipeStream to get the close path working correctly. It's probably going to need some experimentation to know for sure.

[halter73]

Do we want to add the named pipes transport by default? Could this hurt trimming? @eerhardt

[JamesNK]

I don't expect name pipes would include much. The types are thin wrappers around Win32 APIs on Windows and System.Net.Socket on Linux. However, it would be good to measure.

If the named pipes transport factory isn't registered by default, then we'd need to make sure that calling ListenNamePipe has a clear error message about how to register it.

[davidfowl]

It will hurt trimming but I'm sure we're going to end up with a new API that turns most of these off by default.

[JamesNK]

Not a problem if excluded by empty/slim builder.

[mconnew]

This dovetails into the conversation going on in the thread model. Do you want to support connecting to other hosts? Is allowing a serverName intended to make this api represent the concept of a NamedPipe endpoint and as it has a server name, you're enabling representing it? Or is the intention to allow cross machine communication?

[mconnew]

I just followed the flow of this object through and I'm convinced that for a service side application, including serverName doesn't make any sense. You only pass the path to NamedPipeServerStream as you can't create a named pipe on another host. NamedPipeServerStream inserts \\.\pipe\ in front of the pipe name that you pass.

[JamesNK]

We added the server name here if someone wants to use this endpoint in a client. When Kestrel starts up, it validates that the server name is ..

[mconnew]

It's a little bit more complicated than this. If the app is running in a Win32 App Container (think Windows Store app, NOT docker style container), then the pipe name needs to be of the format "\\{ServerName}\pipe\Local\{PipeName}" as apps in a Win32 app container can't create named pipes in a non-local namespace. Or do you expect users to include the Local\ part passed in as the pipeName?

[JamesNK]

The user would add Local\ to the pipe name. PipeName is passed directly to the pipe ctor, and it expects local as part of the name, e.g. new NamedPipeServerStream(@"Local\MyPipeName")

[ghost]

@JamesNK, this change will be considered for inclusion in the blog post for the release it'll ship in. Nice work!

Please ensure that the original comment in this thread contains a clear explanation of what the change does, why it's important (what problem does it solve?), and, if relevant, include things like code samples and/or performance numbers.

This content may not be exactly what goes into the blog post, but it will help the team putting together the announcement.

Thanks!

[simonferquel]

It seems this is never used

[simonferquel]

Ah nvm, it is used for cross-process protection, I see it from the connection factory