Is it availble to do RPC requests from server to client with gRPC?

[fsl...@gmail.com]

Foreword:

I didn't use gRPC before. I only doing first look on this technology and trying to understand can i use it in my project or no.

I using C# with net core 2.1, if it matters for something.

Question:

I have one server and miltiple clients and i need to do rpc requests from server to clients.

Is it availbale with gRPC? And if yes, then how can i do that?

[Ivan Penchev]

The only way to do this is, for the client first to contact the server.

Then on the server you get an IServerStreamWriter<T>, which gives you an option to steam to the client .

The reason you can do it the other way is, that the server must know all the IP addresses to connect to :) 

[fsl...@gmail.com]

четверг, 1 ноября 2018 г., 16:02:25 UTC+5 пользователь Ivan Penchev написал:

The only way to do this is, for the client first to contact the server.

Then on the server you get an IServerStreamWriter<T>, which gives you an option to steam to the client .

The reason you can do it the other way is, that the server must know all the IP addresses to connect to :) 

It is ok, if client should connect to server before any requests from server.

But if i understand correctly,  IServerStreamWriter<T> is one-direction streaming from server to client.

But how to organize rpc requests (request-response model) from server to client, if we already have established connection from client

[Josh Humphries]

You can use a bi-directional stream, where each message that the server sends on a stream will have a single message from the client in reply. The actual request and response types can both have a oneof: the response message has an option in the oneof for each actual RPC operation (and its request type); the request message (sent by the client) would actually define the response types. You can see an example of something like this in the server reflection service. However, that is a normal client-to-server sort of RPC. You'd just swap the request and response types (and have the server be the one that initiates requests by sending a "response" message first, and getting a "request" in reply).

For graceful tear-down, the server will simply have to stop using the stream for sending requests, wait for replies to all outstanding operations, and then close the stream/terminate the RPC. When the client is shutting down, it could stop accepting messages from the server (after every one received, send an immediate error message along the lines of "shutting down").

If you want to support out of order execution (e.g. client replies can be sent in different order than server requests were received), then the request and response schemas will need to have an envelope with some sort of request ID, to correlate replies with their original request.

Aside: I've been working on something you may find useful -- a generic mechanism for tunneling gRPC. The tunnel is setup via a gRPC service that provides the same functionality as a low-level gRPC transport. There are a few interesting use cases, but the server-to-client one is the most interesting IMO. If you're curious, you can poke around at the work-in-progress: https://github.com/jhump/grpctunnel. (Unfortunately, I don't know when I'll get around to really finishing this library, but it may have some interesting ideas/code you could use.)

 

--
You received this message because you are subscribed to the Google Groups "grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+u...@googlegroups.com.
To post to this group, send email to grp...@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/f76852bf-4768-4a75-8bfd-8c174b8626db%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[fsl...@gmail.com]

Josh Humphries, thank you very much for detailed answer!

I am not familiar with go, but i think that i can get some ideas and concepts from your code.

четверг, 1 ноября 2018 г., 20:04:51 UTC+5 пользователь Josh Humphries написал: