On Wed, Sep 12, 2018 at 9:05 AM robert engels <reng...@ix.netcom.com> wrote:
> Hi, I am adding a remote component to my github.com/robaho/keydb project > and decided to use gRPC. > > I’ve reviewed the docs, and it appears to want to be stateless - which > given the nature of Google makes sense. > > But for something like a database connection, where there could be > substantial connection setup costs that you wouldn’t want to pay on every > request, what is the best way to accomplish this with gRPC? > > There are issues like https://github.com/grpc/grpc-go/issues/297 that are > closed with no resolution ??? > > There doesn’t seem to be a way to access the connection state on the > server - to know the associated user, register a close handler, etc. > > The only solutions I see is are > > 1) that the client must send heartbeat message, if the server doesn’t > receive a heartbeat in X, clean-up the connection, AND the client must send > a connectionID along with every request (but even this seems problematic > for security reasons). > > 2) use the bidirectional streaming mode, and so the connection is treated > as one long stream of messages in and out, and when the rpc finishes the > connection is cleaned up > I think you want this mechanism -- the stream. Since gRPC clients assume statelessness, approach #1 will not only need some keep-alive mechanism, but it also requires "smart" routing/affinity, so that all requests for the same "connection ID" get routed on the same socket. Otherwise, you will not be able to do any sort load balancing, since different requests can be scattered to different backends. With a single stream, all messages sent on the stream will be destined for the same backend. For an example of a bidi streaming RPC call that sends/receives sequential request-response pairs on its stream, checkout service reflection <https://github.com/grpc/grpc/blob/master/src/proto/grpc/reflection/v1alpha/reflection.proto#L21> . On a separate note: I've actually started toying around with a library for "tunneling" with gRPC. This library would provide helpers to wrap a protoc-generated stream interface in a more user-friendly API, if you choose to define a streaming endpoint similar to reflection. But it also provides the ability to create a "tunnel" from client to server that acts like a normal gRPC connection but guarantees that all requests are always routed to the same server (basically, gRPC-over-gRPC). It will even support "reverse tunnels", where a gRPC server can act as a client to invoke services exposed by the gRPC client. If any of that is interesting to you, let me know, and I can share some in-progress code with you. > > Is there an example of this type of usage someone can point me to? > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
