grpc-js: Support Unix domain sockets and Named pipes

[raksooo]

This is an attempt at implementing support for UDS and Named pipes as discussed in #258. I'm not sure if the design of this solution is the way to go here or if there's a better way to do it.

As I understand the http2-library, it isn't able to create a connection over a Unix domain socket or a Named pipe. To solve that I opened a connection using the net-library and supplied that connection to http2.connect, as in the example by @jcantwell-JC in the issue mentioned above.

I added a method to the resolver which decides if the connection should be an IPC connection, which works well, but I'm not sure if this is the best way to accomplish this.

[linux-foundation-easycla]

One or more committers are not authorized under a signed CLA as indicated below. Please click here to be authorized. For further assistance with EasyCLA, please submit a support request ticket.

• ❌ Oskar Nyberg (b14d4c6, c895192)

[thelinuxfoundation]

Thank you for your pull request. Before we can look at your contribution, we need to ensure all contributors are covered by a Contributor License Agreement.

After the following items are addressed, please respond with a new comment here, and the automated system will re-verify.

• User @raksooo isn't covered by a CLA. They will need to complete the form at https://identity.linuxfoundation.org/projects/cncf

Regards,
CLA GitHub bot

[murgatroid99]

I'm sorry, we're unlikely to accept this. The API of this library is supposed to match the API of the grpc library, and that one does not have the '//./pipe/` URI scheme. The valid URI schemes are listed in this document.

On the plus side, I have a different change in the works to fix UDS support and the unix: scheme, and once that works, it should be possible to pass a named pipe path using that scheme. For example, unix:///./pipe/pipename should work.

[murgatroid99]

The alternate fix I referred to is in #1245.

[faern]

The documentation you link to says

unix:path or unix://absolute_path -- Unix domain sockets (Unix systems only)

Would it then not be strange to support Windows named pipes through the unix: prefix? Don't get me wrong, we do need named pipes support, but this felt like a strange way to solve it 🤔

EDIT: I should also say that I like your PR. Feels clean to properly separate IPC addresses from http-over-tcp based addresses.

[faern]

It surprises me that gRPC itself specifies address naming schemes at all. Quite limiting to let the protocol library handle the transport layer or express opinions about it. Even more so if it imposes these limitations/requirements on other implementors.

[murgatroid99]

The point about the unix: scheme applying specifically to UDS is fair, and I'm not actually sure if it works that way in the other libraries. But the fact is that in terms of name transformation and connection establishment, the Node APIs do not distinguish between Unix domain sockets and Windows named pipes. That means that there's no substantial difference between code that supports UDS and code that supports named pipes.

Regarding naming schemes, I want to note that that specification does not constrain the gRPC protocol, just the official gRPC libraries. The linked document describes how the gRPC libraries handle and resolve the names passed to them.

I don't see the issue with the gRPC libraries handling name resolution and the underlying transport. The Node http2 library automatically does DNS resolution and establishes the underlying TLS or TCP connection used by the http2 session. That seems like the same thing to me.

[faern]

Having all IPC under the unix: prefix is fine. It should just have been named something else IMO. After all, UDS is named pipes for unix platforms. So named pipes is the broader term. But I get that gRPC originally came from a server infrastructure point of view, os unix support was probably the only support considered at some point :)

I agree it's handy that libraries do have handy helper functions for the most common use cases. But to actually be flexible they should also accept an arbitrary IO stream to operate over. So people with not-default use cases can just plug in their transports. So I agree it's nice that the official libraries can handle a number of URIs out of the box, but it should not limit the user to those IMO.

[murgatroid99]

As I am discovering in my own change, even the built in http2 library doesn't actually make it that easy to just plug in a transport. If you look at the latest version of the PR I linked to, you can see that I still need to set the createConnection option, but only sometimes.

In the longer run it may be possible for grpc-js to eventually support plugging in transports and/or resolvers, but that's another issue of compatibility with the other implementation.

[raksooo]

Thanks for the feedback! It didn't cross my mind to use "unix:" for Windows Named pipes although it's pretty clear that it works when looking at the code. I don't know where but it would be nice if it is documented somewhere.

Your PR looks really good and works well. Thanks for taking the time to implement this! Feel free to close this PR.