The streaming mechanism seems to be the solution. Appears to be how cockroachdb does it.
Sent from my iPhone > On Sep 12, 2018, at 2:47 PM, Josh Humphries <jh...@bluegosling.com> wrote: > > >> 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. > > 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.
