On Thu, Nov 1, 2018 at 8:16 AM <[email protected]> wrote: > > > четверг, 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 >
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 <https://github.com/grpc/grpc-go/blob/master/reflection/grpc_reflection_v1alpha/reflection.proto#L24>. 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 [email protected]. > To post to this group, send email to [email protected]. > 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 > <https://groups.google.com/d/msgid/grpc-io/f76852bf-4768-4a75-8bfd-8c174b8626db%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- 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 [email protected]. To post to this group, send email to [email protected]. 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/CAO78j%2BKqmAkvktXRbmMSYgQ9qozeY%3D7WgQtJtzBUX9hiB_f7kQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
