grpc-node: Unable to connect to Unix socket using node-grpc client
I am trying to communicate with a server that is listening on a unix socket - if I use TCP I have no issues, but after much effort have been unable to get it working with the unix socket. Code is
const BIND_SOCKET = '/tmp/collector.sock';
const BIND_TCP = ':9832'; // works fine if I use this for client + server
const PROTO_PATH = './Collector.proto';
const collector = grpc.load({ root: __dirname, file: PROTO_PATH }).collectorv1;
this.client = new collector.Collector(BIND_SOCKET, grpc.credentials.createInsecure());
I have tried many variations on the socket, such as unix:/tmp/collector.sock and many others I have found online. However none of them work and my write call simply hangs forever, regardless of whether the server is active and listening on the port.
I am using grpc version 1.10.1
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 10
- Comments: 68 (21 by maintainers)
I think we can consider this issue to be an actual feature request 😃 Also it might be easier for us to implement this using the pure-javascript version of the library.
@entropitor : Problem with authority header is a story of its own. It is a source of various interoperability issues because the spec does not say what authority header should be if used over UDS. Related issue to grpc implementation in golang (contains a link to rust issue as well) here: https://github.com/grpc/grpc-go/issues/2628.
I have a speculative fix for this grpc-js problem in #1245.
I’m not exactly sure when we will consider the library production-ready, but the Google Cloud API client libraries have been using it officially for a while.
您好，您的邮件我已经收到！
For those looking to get around the authority header issue and/or work as a uds on windows I created this: https://github.com/democratic-csi/csi-grpc-proxy
It’s a simple proxy written in go which has work-arounds for both issues. I use it successfully to listen on a uds on windows and proxy to a nodejs named pipe etc. I also use it on linux to rewrite the host header before the request is sent to nodejs uds.
Despite the name, it will work in non-csi scenarios. It does not support ssl in any way so only h2c works. It does support tcp so you can mix/match any protocol of tcp/uds/npipe for up/down stream.
The releases have pre-compiled binaries for all supported go os/arch and docker images are produced for windows/linux.
If I’m understanding what’s happening here correctly, Node is rejecting the request before grpc-js ever sees it. grpc-js can’t do anything about that.
Yes,
Server#bindAsyncshould now accept exactly the same set of URLs that can be used to construct the client.I’m sorry that I haven’t addressed this earlier. Unfortunately, the linked PR grpc/grpc#18435 has gotten stale again and has merge conflicts. If @jkryl updates it I will review it as soon as possible.
As for the
@grpc/grpc-jsissue, it looks like theunix:address handling was simply implemented incorrectly. I will look into fixing that.Changing the credentials like that is not a great workaround because that is an implementation detail that just coincidentally does what you want.
@faern : if you can leave a comment in https://github.com/grpc/grpc/pull/18435 that you would like this feature implemented, that might raise the priority of the feature in eyes of grpc maintainers. It’s not moving anywhere currently. thanks
So yes, node-grpc uses the grpc-core library under the hood. However, for nodejs integration, it uses the libuv codepath, which doesn’t have uds integration. Adding uds to node-grpc would mean changing the name resolver of this file to have the same hack as this other file, and then we’d need to plumb the whole concept of libuv pipes into it.
This isn’t trivial, that is.