[grpc-io] Re: How to read grpc command line tool error messages from the responses?

Did you ever figure it out? I would love to know! I'm running into the same problem. On Friday, February 10, 2017 at 7:41:54 AM UTC-8, Sanket Lawangare wrote: > > I am using the grpc command line tool to test response for my request. > This is the official link to the grpc command line tool:

Re: [grpc-io] Re: Guidance on implementing support for authenticated and secure client connections

I do not think we support that. Actually I think tokens are intentionally dropped if the channel is not secure to avoid leaking the tokens over the wire. On Wed, Feb 7, 2018 at 3:04 PM, wrote: > I was able to get this working by simply calling AddMetadata on the client

Re: [grpc-io] Random completion queue "ok" value when an asynchronous streaming RPC client pinging a dead service

Hi Vijay, Thank you very much for the reply! 1. "Finish will always give an ok of 1", I think this is clear and makes perfect sense. This is corresponding to the last "ok" print in my log: Tag received: 0x2419440, Completion queue/Next() returned: 1 HandleEachResponse_FINISH_BAD 2. I read that

[grpc-io] Re: Guidance on implementing support for authenticated and secure client connections

I was able to get this working by simply calling AddMetadata on the client context to set the authorization header. This appears to work for both secure and insecure connections, so I'll go with this approach rather than using the custom authenticator. On Wednesday, 7 February 2018 12:20:11

[grpc-io] Re: USB transport

As Mark mentioned, it's not on our roadmap, but if you wanted to put one together, I can suggest https://github.com/grpc/grpc/blob/master/doc/core/transport_explainer.md for an idea of what transports need to do. If the goal is a simple message-oriented transport without reference to complex

Re: [grpc-io] Random completion queue "ok" value when an asynchronous streaming RPC client pinging a dead service

Hi there, "ok" is documented at https://github.com/grpc/grpc/blob/master/include/grpc%2B%2B/impl/codegen/completion_queue.h#L124 . Finish will always give an ok of 1 since it's always ok to be done with your RPC and check its status. When starting an RPC, ok will give 0 only if gRPC is sure

Re: [grpc-io] Re: Managing linux devices

Your flow is correct. Is it RPC? I guess that's a more philosophical, but I don't think there is anything wrong with it. Streaming RPCs are already kind of weird anyway. A more pure solution would be something akin to tunneling, where a client connects to a server, but then runs a gRPC

[grpc-io] Random completion queue "ok" value when an asynchronous streaming RPC client pinging a dead service

I started learning grpc very recently, and followed the docs/instructions and discussions online to build a toy program of an asynchronous streaming RPC client (.proto and client.cc are attached below). *My grpc version is 1.8.4.* My main idea for this client is to create a "listener" in a

Re: [grpc-io] Re: Managing linux devices

Got it. So this isn't considered bad form for RPC? Technically it isn't RPC? In my case: - Server implements rpc Link (stream UpLink) returns (stream DownLink) {} - Client initiates connection - Client waits for messages to come down from the server to be executed - Clients parses the

[grpc-io] Guidance on implementing support for authenticated and secure client connections

I'm looking into how to support client connections to disparate services using custom oAuth2 tokens. The services may or may not support SSL/TLS. I have created a custom authenticator plugin following the sample code at https://grpc.io/docs/guides/auth.html. I build my custom call credentials

Re: [grpc-io] Re: Managing linux devices

Yes, that is correct. (It's bidirectional because the word "stream" is in both the request (UpLink) and response (DownLink).) I mistakenly thought this was another thread (which I replied to yesterday) which had almost the same issue. Take a look at

Re: [grpc-io] Re: Managing linux devices

I'm unclear on what the last part means: "That's why that issue, (and my post), suggest treating the message as inverted requests and responses." Do you mean rpc Link (stream UpLink) returns (stream DownLink) {} ? With a bidirectional stream? Thanks On Wed, Feb 7, 2018 at 11:27 AM, 'Carl

Re: [grpc-io] Re: Managing linux devices

It's unlikely that gRPC will be able to have servers initiate connections / rpcs to clients. The initial headers need to be sent by the client to the server, and only the server can send trailers to indicate the RPC is done. But, after these two, the client and server are peers. That's why

[grpc-io] Re: Client Timestamp

If I understand correctly, your server interceptor wants to know the time when the RPC is started on the client. Yes you can write a client interceptor that adds the timestamp to the headers. On Tuesday, January 30, 2018 at 7:50:00 PM UTC-8, vicva...@gmail.com wrote: > > I am using java --

Re: [grpc-io] USB transport

It is actually very useful for communicating with microcontrollers. We do something similar with just sending protobuf request responses using nanopb. Our microcontroller is resource limited so running the full grpc stack is not feasible on that side, but might be useful in other situations. On

Re: [grpc-io] USB transport

As far as I know, no one has requested this before, so it's not on our roadmap. What is your use-case for this? I'm not familiar with USB HID, but a quick web search indicates that it's for connecting things like keyboards and mice via USB, and it's not clear to me why you'd want to use gRPC for